Other ideas for memory leak protection

[Sylvain Laurent <sy...@m4x.org>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org