Classloader Leak with WebLogic

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Several redeployments of a web-app with javamelody 
2. A datasource is configured in the jndi tree (weblogic)

What is the expected output? What do you see instead?
If the web-app is redeployed the GenericClassLoader could not be garbage 
collected, because th JdbcWrapper is registered with the OIDManger from 
weblogic, which is loaded by SystemClassloader
see attached screenshot

Solution:
Please provide an ServletContextListener which rewrite the Jndi Bindings with 
the unwrapped Datasources. I think the JdbcWrapper has this kind of 
functionality already.

What version of the product are you using? On what application server, JDK,
operating system?
- weblogic server (10.3.5)

Please provide any additional information below.
See 
http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-
leaks-with-eclipse-memory-analyser-mat/

Ist a very well written article about classloader leaking, and how to find and 
solve them.

Original issue reported on code.google.com by eisele.s...@freenet.de on 23 Dec 2013 at 8:35

• Merged into: #476

Attachments:

• ClassloaderLeak.JPG

[GoogleCodeExporter]

Yes, I know classloader leaks.
- What version of javamelody do you use?
- If you use v1.43 or later, can you put a debug breakpoint in 
JdbcWrapper.unwrapDataSource to see if it works or not for WebLogic?

Original comment by evernat@free.fr on 23 Dec 2013 at 10:10

• Changed title: Classloader Leak with WebLogic

[GoogleCodeExporter]

I used javamelody v1.33. With the new version 1.48 the problem with the 
JdbcWrapper is solved. Sorry for not using the newest version!

Maybe there is another classloader leak, when the "Gui" is started. It seems, 
that the AWT-Thread is started, which loads the class AppContext with the 
GenericClassLoader. (see the other screenshot)

I have not checked, if javamelody or jrobin starts the AWT-Thread.

For me, it is not so relevant because I now use the 
ClassloaderLeakPreventionListener mentioned above, which solves this leak.

Thanks for the great tool!!

Original comment by eisele.s...@freenet.de on 29 Dec 2013 at 3:28

Attachments:

• MemoryLeakAppContext.JPG

[GoogleCodeExporter]

OK for the JdbcWrapper.

Yes, the AWT thread is started by the jrobin library. That's because JRobin 
(org.jrobin.graph.ImageWorker) uses java.awt.image.BufferedImage and its 
createGraphics method to draw graphics (and also ImageIO to create PNG). The 
createGraph method in BufferedImage creates the AWT thread.

I have looked at classloaders in Tomcat with heapdumps. In Tomcat, the class 
sun.awt.AppContext is loaded by the system class loader and not by the webapp 
class loader. It seems that there is no leak with that in Tomcat.

If we would want to fix the AWT thread issue in WebLogic, perhaps we could add 
something like the following (before creating the first graph in 
net.bull.javamelody.JRobin#graph) :

            final ClassLoader loader = Thread.currentThread().getContextClassLoader();
            try
            {
                // Use the system classloader as the victim for this
                // ClassLoader pinning we're about to do.
                Thread.currentThread().setContextClassLoader(
                        ClassLoader.getSystemClassLoader());

                // Trigger a call to sun.awt.AppContext.getAppContext(). This
                // will pin the system class loader in memory but that shouldn't
                // be an issue.
                ImageIO.getCacheDirectory();
            } finally {
                Thread.currentThread().setContextClassLoader(loader);
            }

If you want to test that code in WebLogic, let us know.

Original comment by evernat@free.fr on 30 Dec 2013 at 1:37

[GoogleCodeExporter]

Hi Eisele,
Do you want to test some code in your weblogic webapp?

Original comment by evernat@free.fr on 22 Feb 2014 at 4:56

[GoogleCodeExporter]

The fix for the issue 476 should also fix the the AppContext 
contextClassLoader, so resolving this issue as duplicate/fixed.

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

• Changed state: Duplicate