tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat 8, 8.5 and 9 returning another apps environment with context.lookup() from a .parallelStream()
Date Mon, 09 Jan 2017 20:32:42 GMT
On 09/01/2017 19:57, Christopher Zinn wrote:
> Thanks for the information.  I was not expecting such a great response so
> quickly.
> We are going to test the workaround that sets the java.util.concurrent.
> ForkJoinPool.common.threadFactory property as that will be the easiest for
> us to configure and deploy to our Tomcat instances.

The correct value for that property is:


As I dig into this further, I realise it isn't that simple.

1. There will still be a memory leak.

2. The threads will have the wrong thread context class loader and your
JNDI lookups will fail.

3. ForEach is hard-coded to use the common ForkJoin pool.

As far as I can see, you only option is to correctly set the thread
context class before you do the JNDI lookup. Because of the way the
ForkJoinPool is written that is going to prevent the code ever running
under a SecurityManager (which may not be an issue for you) because
InnocuousForkJoinWorkerThread is hard-coded to throw an Exception if you
call setContextClassLoader().

It looks like ForkJoin was not designed with a multi-class loader
environment in mind. We should be able to get most of this fixed but
without adding significant complexity, the end result is going to be
that ForkJoinWorkerThreads always use the system class loader. That
means if you want to use JNDI, you are going to have to set the thread
context class loader yourself.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message