1 Reply Latest reply on May 14, 2009 4:52 AM by jaikiran pai

    EJB3 Classloader leaks?

    Kevin Mudrick Newbie

      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 pai Master

          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.