geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Cabrera <>
Subject RE: Thread pool strategy
Date Fri, 09 Jul 2004 22:33:37 GMT
I'm probably being fussy but, I think that the interface should belong
to Geronimo, not concurrent.  If I want to supply my own thread pool, it
seems odd that I have to implement an interface from Concurrent.


-----Original Message-----
From: David Jencks [] 
Sent: Friday, July 09, 2004 5:55 PM
Subject: Re: Thread pool strategy

What I have now is a gbean that:

you can either use Executor through the GBean calling mechanism or if 
you think that is too slow get the underlying Executor itself.

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.

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,
>> 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
>> 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

        Visit our Internet site at

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

View raw message