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: java.util.concurrent.ForkJoinPool$ForkJoinTaskFactory 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
