DO NOT REPLY [Bug 33711] New: - Memory leak (classloader) with Log4J and Single Sign On.

[bu...@apache.org]

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: kap@apama.com
                CC: kap@apama.com


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