Bugs item #890030, was opened at 2004-02-03 14:52 Message generated for change (Comment added) made by genman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=890030&group_id=22866
Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Elias Ross (genman) Summary: SimpleTimer is an inefficient use of resources Initial Comment: The class org.jboss.mq.server.SimpleTimer causes two resource problems. 1) The SimpleTimer extends Thread. This means that unless the thread is actually started, its reference in its threadgroup is never cleaned up. This only happens when the thread exits, so not starting the thread causes a memory leak. This also confuses the thread count within the VM which counts the number of Thread objects that haven't exited. It should implement Runnable. 2) We cannot have one thread per queue/topic subscription. It simply will not scale. e.g. if a topic has 100 subscriptions that would mean 100 threads. The implementation needs to be changed to use a thread pool with events as Runnables. A single thread can monitor when the next event is due. See for example the TimerTask in the common project or the RunnableScheduler in the jmx project. The TimerTask seems more appropriate since the events only need to happen once. In my experience, the other option java.util.Timer does not behave efficiently under stress. Regards, Adrian ---------------------------------------------------------------------- >Comment By: Elias Ross (genman) Date: 2004-02-06 00:05 Message: Logged In: YES user_id=556458 I checked in the easy fix I talked about... It would be a lot of work to get "removeAllMessages()" to cancel scheduled messages. If a single Runnable queue were used in DestinationManager, it wouldn't be possible to find which scheduled messages belong to which queue. There might be some way to set a counter to indicate the first message ID from the non-canceled message set. (Specifically, invalidate all messages with IDs less than X.) I'll have to think about it. ---------------------------------------------------------------------- Comment By: Elias Ross (genman) Date: 2004-02-03 18:56 Message: Logged In: YES user_id=556458 src/main/org/jboss/util/WorkerQueue.java (parent of TimerQueue) which uses TimerTasks is pretty much the same implementation as the SimpleTimer. I would expect the same sort of memory leak if TimerQueue was used instead. I think the interm fix would be to lazy-create the Thread in SimpleTimer, in other words keep the instance variable null until a message is scheduled or set to expire. A better fix as you suggest would be to create some sort of centralized (essentially singleton) ThreadPool. Since we don't want this to be static, it would be better to have it made available via JMX. Since I don't have a lot of time to work on this better fix, and moreover I don't need this fix for my own project, I will hope somebody else would contribute code. (Ideally, in JBoss 4.0 or whatever, you'll have the ability to create Invocations which are delayed/scheduled/async. and optionally cancelable as part of the AOP stuff.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=890030&group_id=22866 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
