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 19:33:35 GMT

On Jul 13, 2004, at 11:47 AM, David Jencks wrote:

> On Tuesday, July 13, 2004, at 06:36 AM, Geir Magnusson Jr wrote:
>> 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'?
> Not with the plain ThreadPool.  With the jca WorkManager you can 
> request the work be done "now" (returns after work completes), 
> "started", (returns when thread pool starts executing the task), or 
> "scheduled" (returns immediately, executes at unknown time in future).

I don't know about the workmanager, or if the following makes any real 
sense :

Is it really "now" as in "if you don't have to wait for a thread, do it 
- otherwise return w/ a status indicating now wasn't possible" or "now 
as in  "wait until there's a thread, do it, and then return to me"?


> david jencks
>>> 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)
Geir Magnusson Jr                                   203-247-1713(m)

View raw message