geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From michael <>
Subject RE: Thread pool strategy
Date Sat, 10 Jul 2004 12:42:22 GMT
There are virtually, if not really, no strings attached to Doug's work and 
it will be what we see in J2SE 1.5.

At 03:33 PM 7/9/2004, you wrote:
>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