Hello, we are using a 3rd party lib/framework in our application. During undeployment we see a warning about a possible memory leak:
org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal.SuppliedThreadLocal] (value [java.lang.ThreadLocal$SuppliedThreadLocal@1a14329f]) and a value of type [org.apache.xxx] (value [org.apache.xxx]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. I dug into the sources and found a class A which has a static ThreadLocal variable (let's call it tl). During undeployment there is a tl.remove() in the shutdown method. The warning is logged despite that. The framework is spawning several threads which might use class A and its threadlocal variable. Is it correct, that every spawned thread must call tl.remove() to cleanup all the references to prevent the logged warning (and not only the main thread)? Second question is: How might it cause a memory leak? The threads are terminated and hold a reference to this static variable. But on the other side, that class A is also eligible for garbage collection after undeployment. So both, the thread class and the class A are ready to get garbage collected. Maybe I missed something (?) Before filing a bug report to the maintainer of this lib, I would need to understand the cause and background of this log entry. Thanks in advance! Thomas
