geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: Thread pool strategy
Date Fri, 09 Jul 2004 23:05:17 GMT
On Jul 9, 2004, at 2:54 PM, 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.

GBean proxies are very fast, so I doubt that this direct hook is 
needed.  On my mac the overhead of an invocation 300ns, and on a 
decently fast computer it is well under 100ns.  Anyway, I suggest we 
remove the direct hook (and any others we may have) until it is proven 
to be a performance problem, as a GBean proxy is controllable so we can 
reduce the possibility of memory leaks.

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

Works for me.

-dain


Mime
View raw message