From dev-return-7749-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Sun Jul 11 16:41:29 2004
Return-Path:
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 12730 invoked from network); 11 Jul 2004 16:41:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur-2.apache.org with SMTP; 11 Jul 2004 16:41:29 -0000
Received: (qmail 34377 invoked by uid 500); 11 Jul 2004 16:41:26 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 34150 invoked by uid 500); 11 Jul 2004 16:41:24 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
list-post:
Reply-To: dev@geronimo.apache.org
Delivered-To: mailing list dev@geronimo.apache.org
Delivered-To: moderator for dev@geronimo.apache.org
Received: (qmail 33891 invoked by uid 99); 11 Jul 2004 16:40:57 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Message-ID: <40F16D87.8010904@hiramchirino.com>
Date: Sun, 11 Jul 2004 12:40:39 -0400
From: Hiram Chirino
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Thread pool strategy
References: <98B7B9B4-D1F2-11D8-AE37-003065F4889C@coredevelopers.net>
In-Reply-To: <98B7B9B4-D1F2-11D8-AE37-003065F4889C@coredevelopers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N
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.
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
>>
>