ClassLoader leak when using the reports and then hot-redeploy with Tomcat 7.0.42 or later

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Add javamelody to the "example" webapp which is bundled with Tomcat.  I did 
this by placing javamelody.jar and jrobin-1.5.9.1.jar into the 
webapps/examples/WEB-INF/lib directory.  Then I added the following lines from 
the user guide to the web.xml file:
        <filter>
                <filter-name>javamelody</filter-name>
                <filter-class>net.bull.javamelody.MonitoringFilter</filter-class>
        </filter>
        <filter-mapping>
                <filter-name>javamelody</filter-name>
                <url-pattern>/*</url-pattern>
        </filter-mapping>
        <listener>
                <listener-class>net.bull.javamelody.SessionListener</listener-class>
        </listener>

2. Click on the "Find Leaks" button in the Tomcat Manager.  No leaks should be 
found.

3. Reload the webapp using the Tomcat Manager

4. Click on the "Find Leaks" button in the Tomcat Manager.

What is the expected output? What do you see instead?
Start Tomcat and check for leaks.  No leaks are found.
Reload the example webapp and check for leaks.  No leaks are found.
Add javamelody to the example webapp and restart Tomcat.  No leaks are found.
Reload the webapp, and now there is a leak.  

The following web applications were stopped (reloaded, undeployed), but their
classes from previous runs are still loaded in memory, thus causing a memory
leak (use a profiler to confirm):
/examples

What version of the product are you using? On what application server, JDK,
operating system?
Tomcat 7.0.42
Java 1.6 or 1.7 or 1.8
Javamelody 1.53 or 1.55
Jrobin 1.5.9.1
RHEL 5

Please provide any additional information below.
Reloading the webapp in the Tomcat Manager is the easiest way to reproduce the 
problem.  A parallel deploy will also trigger the leak.

Original issue reported on code.google.com by ejmo...@gmail.com on 21 Apr 2015 at 3:38

[GoogleCodeExporter]

I have reproduced the issue.
There is indeed a classloader leak when:
- using hot-redeploy
- and using Tomcat 7.0.42 or later
- and the monitoring graphs have been displayed before redeploying.
Only one classloader is leaking, not the ones of every redeploy.

It happens because javamelody uses javax.imageio to display the graphs and 
javax.imageio has a classloader leak inside 
sun.awt.AppContext.contextClassLoader.
Before Tomcat 7.0.42, we were automatically protected of the javax.imageio / 
classloader leak by the JreMemoryLeakPreventionListener of Tomcat.
But since Tomcat 7.0.42, the AppContext protection is unfortunately disabled by 
default in JreMemoryLeakPreventionListener of Tomcat and we are no longer 
protected against the AppContext leak.

This is now fixed in trunk by adding a new protection (revision 4070) and ready 
for the next release (1.56).
Thanks for the issue.

Original comment by evernat@free.fr on 27 Apr 2015 at 11:03

• Changed title: ClassLoader leak when using hot-redeploy the first time with Tomcat 7.0.42 or later
• Changed state: Fixed

[GoogleCodeExporter]

Original comment by evernat@free.fr on 27 Apr 2015 at 11:06

• Changed title: ClassLoader leak when using the reports and then hot-redeploy with Tomcat 7.0.42 or later

[GoogleCodeExporter]

Issue 369 has been merged into this issue.

Original comment by evernat@free.fr on 27 Apr 2015 at 11:10