Bug 38048 - Classloader leak caused by EL evaluation
Summary: Classloader leak caused by EL evaluation
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.17
Hardware: Other other
: P2 major with 3 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2005-12-27 10:23 UTC by Taras Tielkes
Modified: 2006-10-18 23:15 UTC (History)
0 users

Modified WebappClassLoader (from 5.5.17) with EL cache cleanup (76.66 KB, text/plain)
2006-06-26 14:18 UTC, Taras Tielkes
Patch from 5.5.17 (1.93 KB, patch)
2006-06-26 14:45 UTC, Taras Tielkes
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Taras Tielkes 2005-12-27 10:23:24 UTC
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.
Comment 1 Taras Tielkes 2005-12-27 11:03:44 UTC
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:
   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 

Comment 2 Taras Tielkes 2006-06-03 17:58:20 UTC
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:

In later versions (>=9.0) commons-el was dropped altogether (quite wise).
Comment 3 Taras Tielkes 2006-06-26 14:18:09 UTC
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.
Comment 4 Darryl Miles 2006-06-26 14:41:27 UTC
Would it be possible to re-attach as a unified diff format patch ?  Thanks
Comment 5 Taras Tielkes 2006-06-26 14:45:03 UTC
Created attachment 18538 [details]
Patch from 5.5.17
Comment 6 Taras Tielkes 2006-06-26 14:49:10 UTC
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)
Comment 7 Remy Maucherat 2006-06-26 15:58:18 UTC
Your patch seems ok to me.
Comment 8 Taras Tielkes 2006-10-09 01:15:17 UTC
Any chance of getting this one in 5.5.x?
Comment 9 Mark Thomas 2006-10-18 16:32:26 UTC
Fixed in SVN and will be included in 5.5.21 onwards. Many thanks for the patch.
Comment 10 Taras Tielkes 2006-10-18 23:15:20 UTC

I'll check 6.x for similar problems as soon as the first early releases show up.