Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40F16D87.8010904@hiramchirino.com>
References: <98B7B9B4-D1F2-11D8-AE37-003065F4889C@coredevelopers.net>
 <40F16D87.8010904@hiramchirino.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <A5EBBBC4-D4D1-11D8-8606-000A95A01192@4quarters.com>
Content-Transfer-Encoding: 7bit
From: Geir Magnusson Jr <geir@4quarters.com>
Subject: Re: Thread pool strategy
Date: Tue, 13 Jul 2004 09:36:30 -0400
To: dev@geronimo.apache.org


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