Overview The class javax.security.auth.Policy has a static member contextClassLoader that can refer to the WebappClassLoader of an application. If that happens, the web application cannot be garbage collected after undeploy. Steps to reproduce Create a web application that uses Axis 1 as SOAP server. Deploy the web application in Tomcat. Make a SOAP call to the webapplication. Undeploy the web application. Wait an hour. Make a memory dump using jmap, and inspect the memory using jhat. Actual results The WebappClassLoader for the web application is still present. Its "reference chains from rootset" shows a reference like this: System Class Reference : --> class javax.security.auth.Policy (84 bytes) (static field contextClassLoader:) --> org.apache.catalina.loader.WebappClassLoader@0xeb52ba60 (165 bytes) Expected results There is no WebappClassLoader for this web application anymore. Build date & platform Downloaded Core tar.gz from http://tomcat.apache.org/download-70.cgi
Thanks for the report. I have added protection for this to the JreMemoryLeakPreventionListener and it will be included in 7.0.3 onwards.
Reviewing the fix, which is r988296 plus r988429, and whether this should be proposed for 6.0.x, I do not understand the following: There are two Policy classes in JDK 1.6: (1) java.security.Policy (2) javax.security.auth.Policy (@deprecated as of JDK version 1.4 -- Replaced by java.security.Policy) The contextClassLoader field is in (2), but the fix preloads (1) and not (2). So, - how does this fix the issue? - why the issue was observed in the first place? Does Axis 1 make a call to the deprecated class?
Yep, bad import. Fixed in trunk and will be in 7.0.4 onwards. I also proposed a back-port of all the changes to this listener that haven't yet made it into tc6.