Executor support

[Remy Maucherat <re...@apache.org>]

Hi,

I refactored the endpoints for some of the connectors, adding the 
possibility to use an Executor for the worker threads (given the accept 
threads are long running threads, it does not make sense to pool them). 
I would like to add a companion "Executor" element to either Engine or 
Server (I haven't decided, any ideas ?) to be able to define a global 
thread pool (with queuing :) ). I don't think this will be the default, 
as the simple defaults are faster and probably good enough for many 
cases, but in case of large servers with many thread-using services, it 
could be useful to standardize on this common interface to allow sharing 
the thread pool.

Note: At the moment, using the thread pool may cause memory leaks with 
JMX. Also, the threads created are not thread with attributes by default 
which would cause classcasts unless the executor is configured with the 
appropriate thread factory. The solution might be to stop using 
ThreadWithAttributes (which IMO would be logical, as in that case 
threads are not used for a specified service - like a Tomcat connector - 
so tracking their activity does not make sense).

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Executor support

[Remy Maucherat <re...@apache.org>]

Costin Manolache wrote:
> I kind of liked ThreadWithAttributes :-), but I don't think it's
> needed any more.
> However, I think if we stop using it in some cases, we should completely 
> remove
> it, otherwise it's going to be messy.
> 
> ThreadWithAttributes was required long ago when we had JDK1.1 ( no 
> ThreadLocal )
> and with the early implementations of ThreadLocal. I haven't tested, but 
> I hope
> ThreadLocal is now optimized enough - i.e. I assume behaves just like
> ThreadWithAttributes, accessing a 'local' data instead of the
> hashtable lookup by thread.

Yes, TWA was a good idea at the time. I looked quickly at where it is 
used now, and it seems for monitoring RequestInfo is also used. So it is 
possible to remove it.

TheeadLocals are apparently reasonably fast right now. I switched to 
them earlier (for the code that retrieves the processor), and it seems ok.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Executor support

[Costin Manolache <co...@gmail.com>]

I kind of liked ThreadWithAttributes :-), but I don't think it's
needed any more.
However, I think if we stop using it in some cases, we should completely remove
it, otherwise it's going to be messy.

ThreadWithAttributes was required long ago when we had JDK1.1 ( no ThreadLocal )
and with the early implementations of ThreadLocal. I haven't tested, but I hope
ThreadLocal is now optimized enough - i.e. I assume behaves just like
ThreadWithAttributes, accessing a 'local' data instead of the
hashtable lookup by thread.

+1 on removing completely TWA, but -1 on using it in some cases (
well, I think at least one
of the connectors is not using TWA already - but it's not commonly
used and I missed my
chance to -1 it.. )

Costin

On 4/28/06, Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> I refactored the endpoints for some of the connectors, adding the
> possibility to use an Executor for the worker threads (given the accept
> threads are long running threads, it does not make sense to pool them).
> I would like to add a companion "Executor" element to either Engine or
> Server (I haven't decided, any ideas ?) to be able to define a global
> thread pool (with queuing :) ). I don't think this will be the default,
> as the simple defaults are faster and probably good enough for many
> cases, but in case of large servers with many thread-using services, it
> could be useful to standardize on this common interface to allow sharing
> the thread pool.
>
> Note: At the moment, using the thread pool may cause memory leaks with
> JMX. Also, the threads created are not thread with attributes by default
> which would cause classcasts unless the executor is configured with the
> appropriate thread factory. The solution might be to stop using
> ThreadWithAttributes (which IMO would be logical, as in that case
> threads are not used for a specified service - like a Tomcat connector -
> so tracking their activity does not make sense).
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>