1 Reply Latest reply on Mar 19, 2014 5:46 PM by hillside_emc

    Memory Leak with java.security.ProtectionDomain

    hillside_emc

      Hello - We run into a weird memory leak issue with JBoss 5.1 on Linux. A heap dump taken while the JVM was busy doing GC indicated that there were a total of 283,188 objects of java.security.ProtectionDomain.


      We do not use any specific security policy. It appears that most (> 90%) java.security.ProtectionDomain objects were related to geronimo-stax-api_1.0_spec-1.0.jar because there were a large number of duplicate strings that point to the jar location. It appears that the only place where we might have the jar path is java.security.CodeSource. That is why I guess that most java.security.ProtectionDomain objects were related to geronimo-stax-api_1.0_spec-1.0.jar.


      We do not use geronimo-stax-api_1.0_spec-1.0.jar directly. Instead we use Apache POI that uses geronimo-stax-api_1.0_spec-1.0.jar.


      Has anyone seen a similar issue?


      Is there a work-around?  We have tried to work-around the issue by adding geronimo-stax-api_1.0_spec-1.0.jar to JBOSS_CLASSPATH but without success.


      • A class loaded by the primordial classloader does not have associated ProtectionDomain. That is why we tried the above work-around.


      Thanks in advance for help!

        • 1. Re: Memory Leak with java.security.ProtectionDomain
          hillside_emc

          I just wanted to add more info and hope a JBoss classloading expert can help.

           

          After enabling trace for classloading, we see the following repeated messages:

           

          2014-03-19 10:59:41,756 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] (http-0.0.0.0-9080-3) BaseClassLoader@1a7f14f{vfsfile:/opt/dctm67/svr1/share/jboss5.1.0/server/DctmServer_MethodServer/deploy/ServerApps.ear/} load class locally javax.xml.namespace.NamespaceContext

          2014-03-19 10:59:41,756 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] (http-0.0.0.0-9080-3) BaseClassLoader@1a7f14f{vfsfile:/opt/dctm67/svr1/share/jboss5.1.0/server/DctmServer_MethodServer/deploy/ServerApps.ear/} getPackage javax.xml.namespace

          2014-03-19 10:59:41,756 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] (http-0.0.0.0-9080-3) BaseClassLoader@1a7f14f{vfsfile:/opt/dctm67/svr1/share/jboss5.1.0/server/DctmServer_MethodServer/deploy/ServerApps.ear/} already loaded package javax.xml.namespace javax.xml.namespace

          2014-03-19 10:59:41,790 TRACE [org.jboss.classloader.spi.base.BaseClassLoader] (http-0.0.0.0-9080-3) BaseClassLoader@1a7f14f{vfsfile:/opt/dctm67/svr1/share/jboss5.1.0/server/DctmServer_MethodServer/deploy/ServerApps.ear/} load class locally javax.xml.namespace.NamespaceContext

           

          Basically, the class javax.xml.namespace.NamespaceContext is loaded over and over repeatedly.

           

          javax.xml.namespace.NamespaceContext is included in geronimo-stax-api_1.0_spec-1.0.jar. What is interesting is javax.xml.namespace.NamespaceContext is also included in the JVM's rt.jar.

           

          Would that explain why the same class is loaded again and again? And with each loaded class, do we have one ProtectionDomain object created? (That is my guess based on heap dump analysis.)

           

          What would cause it? How can we avoid this issue?

           

          Thanks!