tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Executor support
Date Fri, 28 Apr 2006 16:38:29 GMT
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.. )


On 4/28/06, Remy Maucherat <> 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:
> For additional commands, e-mail:
View raw message