On 09/01/2017 14:29, Mark Thomas wrote: > On 08/01/2017 22:04, Christopher Zinn wrote:
<snip/> >> 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. <snip/> > 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 environment. You have a couple of work-arounds available - Run under a SecurityManager - Set the java.util.concurrent.ForkJoinPool.common.threadFactory system property to java.util.concurrent.ForkJoinPool.InnocuousForkJoinWorkerThreadFactory Meanwhile, I'll be doing the following: - Updating Tomcat's JreMemoryLeakPreventionListener to include protection for this memory leak. - Adding this leak to https://github.com/markt-asf/memory-leaks - Raising a JRE bug - Pinging our friendly Oracle contact to get this fixed (we've been pretty successful at getting this fixed recently) Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
