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 16:57:28 GMT
On 09/01/2017 14:29, Mark Thomas wrote:
> On 08/01/2017 22:04, Christopher Zinn wrote:


>>    We are running into an issue where we have multiple copies of the same
>> WAR loaded on a Tomcat instance each with its own context.xml.
>> The initial problem I was trying to diagnose was A JNDI lookup to a
>> Connection Pool in one of the WARs was returning the connection pool of one
>> of the others.
>> The problem only happens when the JNDI lookup is performed within a
>> parallelStream().
>>    I was able to produce a very simple WAR with a single servlet and a
>> context XML to reproduce the problem I'm having (See below).
>>    If you run the servlet from the first application, it works correctly.
>> You will see that it only ever looks up 'Test 1'.
>> When I run the servlet from the second application it will only return Test
>> 1 in the first part (stream()) but a mix of 'Test 1' and 'Test 2' in the
>> parallelStream() part.


> A quick look at the JRE source code suggests this is handled correctly
> but the code isn't the easiest to trace through. I'll set up the
> provided test case and take a closer look. That may take an hour or two.

I can confirm that the root cause is a JRE bug. Unless you are running
under a SecurityManager the default ForkJoinWorkerThreadFactory does not
take any steps to ensure correct operation in a multi-class loader

You have a couple of work-arounds available
- Run under a SecurityManager
- Set the java.util.concurrent.ForkJoinPool.common.threadFactory system
  property to

Meanwhile, I'll be doing the following:

- Updating Tomcat's JreMemoryLeakPreventionListener to include
  protection for this memory leak.
- Adding this leak to
- Raising a JRE bug
- Pinging our friendly Oracle contact to get this fixed (we've been
  pretty successful at getting this fixed recently)



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

View raw message