geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <>
Subject Re: Thread pool strategy
Date Tue, 13 Jul 2004 13:36:30 GMT

On Jul 11, 2004, at 12:40 PM, Hiram Chirino wrote:

> Hi David,
> If I remember correctly, setting a maxsize on the PooledExecutor can 
> cause deadlocks IF your not careful with the work you give the 
> executor to run.  For example, if the executor is given some work that 
> puts it at maxsize, and that work in turn requests that executor to do 
> some 'other' work and waits for the work to finish, then you get a 
> deadlock since the 'other' work does not run since it's sitting in the 
> LinkedQueue.
> So the moral of the story is just be careful with what you ask the 
> PooledExecutor to execute.

Also - I haven't looked at the interface, but is there a way of 
figuring out out the depth of queue so you can decide not to queue up 
work if it wouldn't happen 'now'?

> Regards,
> Hiram
> David Jencks wrote:
>> What I have now is a gbean that:
>> --interface:
>> you can either use Executor through the GBean calling mechanism or if 
>> you think that is too slow get the underlying Executor itself.
>> --implementation
>> Uses a PooledExecutor with a fixed minsize = maxsize and a 
>> LinkedQueue to put waiting requests on.  This will keep creating 
>> threads until it is full, then put tasks on the queue and freed up 
>> threads will take them off.  This uses standard Concurrent classes 
>> only.  As far as I can tell any other behavior would require us to 
>> write some code, which I would expect to contain some bugs.  Until we 
>> see an actual problem with this strategy I'l like to leave well 
>> enough alone.  My original question was whether anyone knew of 
>> problems we would be likely to run into using this strategy.
>> I plan to modify the JCA WorkManager to use this thread pool gbean.  
>> I'm not quite sure how thread pools are used in network/remoting, but 
>> I'd imagine they are used as gbeans, so you can replace them with 
>> another gbean with a different Executor configuration with no 
>> problems.
>> thanks
>> david jencks
>> On Friday, July 9, 2004, at 10:34 AM, Dain Sundstrom wrote:
>>> On Jul 9, 2004, at 10:32 AM, Aaron Mulder wrote:
>>>>     There is an interface for this in 1.5 (based heavily on Doug's, 
>>>> it
>>>> seems)...
>>> Not surprising considering Doug wrote the stuff in 1.5 :)
>>>>  We may want to accomodate that later, even if we use the
>>>> standalone version for now.  I guess that suggests that we use our 
>>>> own
>>>> Executor interface that happens to be the same as Doug's, so that 
>>>> if we
>>>> later switch the underlying mechanics to JDK 1.5 then we can drop 
>>>> the
>>>> dependency on the standalone concurrency library.
>>> The nice thing about GBeans is you can have a proxy to a GBean that 
>>> implements an interface that the GBean does not.  We simply match up 
>>> the method signatures of "proxy interface" with the signatures of 
>>> the operations and attributes exposed from the GBean.  So in 
>>> Geronimo code we can use our own interface (or the one in 
>>> concurrent) and if users want to use 1.5 interfaces it will still 
>>> work.
>>> -dain
Geir Magnusson Jr                                   203-247-1713(m)

View raw message