geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject Re: Thread pool strategy
Date Tue, 13 Jul 2004 15:47:51 GMT

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).

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@4quarters.com
>


Mime
View raw message