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=33711>. 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=33711 Summary: Memory leak (classloader) with Log4J and Single Sign On. Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] We have detected a situation where Tomcat will leak memory when web applications are undeployed. Specifically, when the following 3 conditions are met: a) SingleSignOn valve is used b) the web app requires the user to be authenticated to get a session c) the web app contains commons-logging.jar *and* log4j.jar This has been observed with Tomcat 5.5.7 Simply deploy a web app under the above conditions, visit the web app so that a session for that app is stored in the SingleSignOn data structures, then undeploy the web app. At this point tomcat leaks a reference to the class loader for the undeployed web app. Repeat, and eventually this will cause OutOfMemoryError. What happens is that an instance of StandardSession is stored as a key in the "reverse" HashMap of SingleSignOn. The instance of StandardSession also refers to an instance of StandardManager in its "manager" field. The classes for the SingleSignOn, StandardSession and StandardManager all appear to be loaded by the "catalina" StandardClassLoader. However, (and I think this is where the leak happens), the "log" field of the StandardManager refers to an instance of: org.apache.commons.logging.impl.Log4JLogger That Log4JLogger class is loaded by the WebAppClassLoader for our web app, hence making a hard reference to that class loader. When the web application is undeployed, the hard reference to the dead classloader remains in the data structures of SingleSignOn. I think it only gets cleaned up when the session is terminated. This has lead to exhaustion of the PermGen for our applications, where it is quite normal to create/deploy/undeploy web applications in production (not just during development). I can supply a very simple web-app to demonstrate this effect if required. Not sure if this is one bug, or several: 1) Why is the logger loaded from the web app class loader? 2) Why does the SingleSignOn mechanism not remove ALL sessions for ALL users related to a given web app when the web app is undeployed. Any ideas for fixes for this? (Its seriously delaying a product release at present.) Many thanks, Kev -- 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]