EJB3 Classloader leaks?

kevinmudrick May 13, 2009 2:44 PM

I am seeing, upon undeployment of an ear the classloader for all my EJBs staying around.

To test, I am deploying, undeploying, deploying, and undeploying again. I then dump heap, and analyze it with the Eclipse Memory Analyzer plugin. Then I look for duplicate classes - and for each duplicate class (all my Stateless Session beans and their interface) I seem to have two instances of the org.jboss.mx.loading.UnifiedClassLoader3. I then follow the path to GC root (excluding soft/weak refs).

Each interface and class then has <JNI Local> java.lang.Thread JDWP Transport Listener: dt_socket

Also, if I call list() on JNDIView in the JMX Console, I see all the EJB implementations listed in Global JNDI Namespace under the [now undeployed] ear. The class for each is org.jnp.interfaces.NamingContext

Any ideas why this is so, or how I can go about eliminating it? It seems to me that I'm going to run out of permgen after lots of redeploys if the classloaders have strong refs to the ejbs and vice versa and cannot be unloaded.

1. Re: EJB3 Classloader leaks?

jaikiran May 14, 2009 4:52 AM (in response to kevinmudrick)

Which version of JBoss do you use? And can you please post the JNDI tree output that shows the binding even after the bean is undeployed? And undeployment logs would also be helpful.

While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.
Actions