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. - Chris On Mon, Jan 9, 2017 at 11:57 AM, Mark Thomas <ma...@apache.org> wrote: > 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 > >
