geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan W.McAdams <>
Subject Re: Thread Management / ClockDaemon
Date Wed, 19 May 2004 00:56:18 GMT
Disregard this last for various reasons - mainly my own idiocy.  Among 
other things, I confirmed with Dain that relying upon JMX for this 
would be bad for a variety of reasons which are best illustrated by him 
[should anyone have questions about this strategy.]

java.util.Timer seems to be the best method, assuming a properly 
implemented TimerTask instance.

On May 18, 2004, at 19:43, Brendan W.McAdams wrote:

> And continuing my self introspective ramble on this issue, and finding 
> there are still informational pieces I need [when does next timer 
> fire? java.util.Timer doesn't provide this in the manner needed]... 
> What about using JMX Timers as the backing provider?  They are part of 
> the J2EE 1.4 Spec [TimerMBean] so we'll have to provide them anyway 
> and they appear to facilitate all of the necessary methods.
> I do recall Dain Sundstrom saying something in a past conversation 
> about being iffy about using them however.
> Thoughts?  I don't think there are any more options than these '3' for 
> me to stumble upon for now and I apologise for exposing a potential 
> inner monologue to the wild.
> -Brendan
> On May 18, 2004, at 17:51, Brendan W.McAdams wrote:
>> On this token, talking to Alan Cabrera and Jeremy Boynes on Freenode, 
>> the question came up about why not just use java.util.Timer; having 
>> looked at it java.util.Timer under 1.4 (We just moved to 1.4 at work 
>> from 1.3 so i'm still not up to speed on the API changes - I hadn't 
>> realised how much Timer had changed) it certainly is a closer 
>> functional match for the needs of EJB timers [clockdaemon provides no 
>> way to check next execution time].
>> One obvious benefit to ClockDaemon is it's ThreadPool is configurable 
>> and conceivably Geronimo could set one that it can control, however 
>> ClockPool currently isn't giving it a managed ThreadPool, and 
>> java.util.Timer as long as EJBTimerService only uses a signle 
>> instance, will only use one thread which can be 'controlled' from 
>> EJBTimerService.
>> For the time being, pending peer review I'm going to give this some 
>> effort with java.util.Timer as the backing timer until we can come up 
>> with something better.
>> -Brendan
>> On May 18, 2004, at 16:12, Brendan W.McAdams wrote:
>>> I'm looking over some more of my design with regards to the EJB 2.1 
>>> timer service, and looking at using ClockDaemons as provided by the 
>>> ClockPool service in o.a.g.system.  Are there any issues I should 
>>> keep in mind working with this?  Are the threads it kicks off 
>>> cleanly managed? (I do notice we're setting an explicit threadpool 
>>> on the clockdaemon within clockpool).
>>> Am I safe using the ClockPool service for this task?
>>> Regards,
>>> Brendan

View raw message