On Aug 14, 2008, at 8:32 AM, Sahoo wrote:
> Scott Oaks wrote:
>> Note that our experience from the grizzly threadpool is that the
>> complexity of the executor service can lead to performance
>> degredations,
>> particularly for lots of short requests handled by a few threads.
> 1. Is this result published anywhere?
> 2. IMO, it should be possible for us to plugin a different
> implementation of thread pool. It is needed in certain types of
> extensions of GlassFish.
>
>
I agree. The intent here is to have a standard threadpool API (like
ExecutorService),
and allow for different implementations. A particular configuration
of GFv3
may need several instances of a Threadpool, some of which may be shared
across multiple components. This is also affected by things like how
we configure
request prioritization.
Someone needs to own the design of this, and publish the ideas for
all to review.
Right now we have 3 different threadpools (at least) in the product:
the JDK 5
ThreadPoolExecutorService (I don't know if this is used in GFv3), the
ORB threadpool,
and the Grizzly threadpool. One model we have discussed is for
Grizzly to supply
the threadpool service to the app server.
Ken.