Community
Participate
Working Groups
Build Identifier: org.eclipse.emf.ecore-2.6.0.v20100614-1136 In our web application, we are directly using ecore for import/export. When shutting down Tomcat (version 6.0.32), or redeploying the web application, we obtain the following error message: Jul 7, 2011 6:03:18 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/testApp] created a ThreadLocal with key of type [org.eclipse.emf.ecore.impl.EClassImpl$1] (value [org.eclipse.emf.ecore.impl.EClassImpl$1@1084b02]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. Reproducible: Always Steps to Reproduce: 1. Start Tomcat with a web application that makes use of ecore internally. 2. Initiate an import/export. 3. Undeploy application or shut down Tomcat.
ThreadLocal Javadoc says * after a thread goes away, all of its copies of * thread-local instances are subject to garbage collection (unless other * references to these copies exist). In general, the instances in the ThreadLocal are an empty set and the only references to them are via the ThreadLocal, so I can't imagine there being a significant leak here. Can you confirm that there is actually a leak rather than "there likely is one"?
The information in http://wiki.apache.org/tomcat/MemoryLeakProtection suggests that this problem is fixed, i.e., it says: Tomcat 6.0.24-6.0.26 "speeds up" the removal of stale entries (and thus fixes the pseudo-leak), by calling expungeStaleEntries() for each thread that has some stale entries. Since it's not thread-safe, it has been made optional and disabled by default from 6.0.27. Tomcat 7.0.6 and later fix the problem by renewing threads in the pool. You could try using the optional feature or upgrading to a newer version of Tomcat...
Well, currently we can't migrate to Tomcat 7.0.6 or newer, although this would indeed fix the problem for us. Nonetheless, the problem might also be present in the case of other web servers (or other packages), where no workaround or a newer version is available.
One can certainly argue that it's a flaw in the web server given that this use of thread locals in EMF follows a standard Java pattern that one would expect to be repeated anywhere. No doubt that's why it's been addressed in the web server itself in this case... It's also not entirely clear how one would fix this problem. This this is private to the EClassImpl, so it can be arbitrarily changed without affecting clients. Do you have a suggestion?
