Hello all, I wrote a wiki page to try and explain all the causes of webapp classloader leaks one might encounter : http://wiki.apache.org/tomcat/MemoryLeakProtection I'd be glad to have your feedback on it !
While creating the page, I thought about 2 things to improve the protection : 1) to fix leaks like "Webapp class instance indirectly held through a ThreadLocal value" ( http://wiki.apache.org/tomcat/MemoryLeakProtection#webappClassInstanceAsThreadLocalIndirectValue ), I think that the only efficient way would be to renew all the threads in the worker pool after an application is stopped. Unfortunately I don't see any way of doing this with the ThreadPoolExecutor that is now used by tomcat 7. We could create a new ThreadPoolExecutor instance, and stop all threads of the old one, but this would have a big performance impact for other running applications... Alternatively, we could clean all ThreadLocals in org.apache.tomcat.util.threads.ThreadPoolExecutor.afterExecute(Runnable, Throwable) . But I don't know the performance impacts that it would have on usual applications. 2) to fix leaks like "Threads spawned by classes loaded by the common classloader" ( http://wiki.apache.org/tomcat/MemoryLeakProtection#cclThreadSpawnedByCommonClassLoader ) while avoiding the side effects of stopping threads (see https://issues.apache.org/bugzilla/show_bug.cgi?id=48971 ), the "expendable classloader" can help. But before trying to provide a patch, I tried to simply nullify the CCL and inheritedAccessControlContext of the "leaking thread" : thread.setContextClassLoader(null); Field field = Thread.class.getDeclaredField("inheritedAccessControlContext"); field.setAccessible(true); field.set(thread, null); I tested it, it works and is much simpler than the "expendable classloader" trick, but I really don't know how safe it is, especially if running with a security manager... What do you think ? Sylvain --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
