The evaluation of JSP 2.0 EL (expression language) in JSP pages can cause BeanInfo metadata of the referenced objects to be cached. This happens in the class [org.apache.commons.el.BeanInfoManager]. Since the commons-el.jar where this class resides is loaded by the "Common" ClassLoader, this causes a reference leak to the Webapp classloader when the BeanInfo refences an object from the Webapp classloader. On webapp shutdown, the container should clear the BeanInfoManager cache, or delete all entries pointing to code loaded from the webapp.
This can be observed by running Tomcat 5.5.9/5.5.14 with a JVMTI profiler attached. Make sure to use a JRE that has (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5093520) fixed, Mustang >= b53 or a prerelease of 1.5 update 7. The observed reference list is: ----------------------------- com.foo.MyEnumClass MY_ENUM_MEMBER of com.foo.MyEnumClass key of java.util.HashMap$Entry next of java.util.HashMap$Entry [28] of java.util.HashMap$Entry[33] table of java.util.HashMap mBeanInfoManagerByClass of org.apache.commons.el.BeanInfoManager [547] of java.lang.Object[641] elementData of java.util.Vector classes of org.apache.catalina.loader.StandardClassLoader commonLoader of org.apache.catalina.startup.Bootstrap [Stack Local] -----------------------------
Sun AS/Glassfish used commons-el in past (<=8.2) versions, exhibiting exactly this problem. This was fixed using a simple patch, manually releasing cached classes on webapp shutdown. See description of bug and solution here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6390584 In later versions (>=9.0) commons-el was dropped altogether (quite wise).
Created attachment 18537 [details] Modified WebappClassLoader (from 5.5.17) with EL cache cleanup I've attached a version of WebappClassLoader.java (from 5.5.17) that cleans up the EL cache (only for classes from the current webapp) on undeploy.
Would it be possible to re-attach as a unified diff format patch ? Thanks
Created attachment 18538 [details] Patch from 5.5.17
With the provided patch a number of big webapps with plenty dependencies now can be properly unloaded, as can be verified using a JVMTI agent (YourKit or other). With this patch, the only leaks I see are InheritableThreadLocals from Spring. (attached to lazy-started subsystem threads like the Java2D Disposer)
Your patch seems ok to me.
Any chance of getting this one in 5.5.x?
Fixed in SVN and will be included in 5.5.21 onwards. Many thanks for the patch.
Thanks. I'll check 6.x for similar problems as soon as the first early releases show up.