DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38716>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38716 Summary: Memory leaking on application undeployment, reload: solution to problem. Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcat indirectly leaks memory on webapp undeployment, due to the fact that the worker threads aren't re-created ever. It has always done so (depending on the java version, actually), but can be _perfectly fixed_. The reason is ThreadLocals, and the application developer will in many circumstances _never_ be able to fix the problem, due to the problem being outside his reach (e.g. in libraries etc). Here is a discussion of the problem: http://www.jroller.com/page/tackline?entry=fixing_threadlocal Here is a bug entry by the same guy. Given sun's response, there isn't much hope here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531 (Please vote for the bug in any case - it is _a huge problem_ for everything that hopes to "reload" an application) Here is another discussion, with a list of likely offenders in the case: http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 An actual fix for tomcat is one of the following: a) On any web application undeployment, get all threads in all pools that can have had anything to do with that webapps classloader to die, and reinstantiate them. b) Make a crude solution where on any webapp undeployment, the same threads as above instead are sent packing into a "clean yourself" method. This method will have to do introspection into the "ThreadLocalMap" instance in the Thread, make the instance accessible (override the private marking), go through all objects there, all objects whose class's classloader is == the instance that we're about to throw, are nulled. Of course, threads that are servicing something will be notified on pool reentry, while threads that currently are in the pool, will be fixed right away. Both of the above will _instantly_ fix most memory-leak-on-reload problems in tomcat. Even if recreating threads are way costly, the solutions above will have no impact in any real setting: reloads aren't done often. In addition, often a Tomcat instance is just running one webapp, or at least the other webapps are just there to feed the one major (a portal springs to mind). So recreating all threads won't do any harm if one is already undeploying (or reloading) the webapp in question. This could be offered as an option in the configuration. .. and it could be a new button to hit in the /manager interface (and JMX): "kill and recreate all threads". PS: On the page "http://tomcat.apache.org/faq/deployment.html"; it is said that the ClassLoader cannot be GC'ed. This is pure BS. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
