[jira] [Created] (CAMEL-5907) Camel leaks memory on undeploy / redeploy in app server when JMX enabled and createConnector = true

["Daniel Gredler (JIRA)" <ji...@apache.org>]

Daniel Gredler created CAMEL-5907:
-------------------------------------

             Summary: Camel leaks memory on undeploy / redeploy in app server when JMX enabled and createConnector = true
                 Key: CAMEL-5907
                 URL: https://issues.apache.org/jira/browse/CAMEL-5907
             Project: Camel
          Issue Type: Bug
          Components: camel-jmx
    Affects Versions: 2.10.0
            Reporter: Daniel Gredler
            Priority: Minor


We have embedded Camel in an EAR that we deploy to Weblogic. The Camel context is configured via Spring:

{code}    <camelContext id="camel" handleFault="true" autoStartup="{{autoStartup}}" xmlns="http://camel.apache.org/schema/spring">
        <contextScan />
        <jmxAgent id="camelAgent" createConnector="true" registryPort="{{jmxPort}}" />
    </camelContext>{code}

You can see that we create a JMX connector to allow for remote management.

However, we have run into PermGen space issues, because our application is leaking class loaders when the application is undeployed or redeployed.

After digging around (and addressing some Jasper Reports ThreadLocal sloppiness), it appears that the only issue left is that the sun.rmi.transport.ObjectTable class maintains a static reference to all available RMI targets. Unfortunately, one of these targets is the JMX connector created by Camel, which was obviously loaded via our application's classloader.

Thus, ObjectTable has a static reference to the Camel JMX RMI target, which has a reference to the app's class loader, which in turn has references to all classes loaded (and generated) for that single deployment of the application -- and none of these classes can be GC'ed.

After digging through the code for Camel's DefaultManagementAgent, I'm inclined to believe that the fix is fairly simple:

# Update {{createJmxConnector(String)}} to cache the reference to the created {{Registry}} in an instance variable.

# Update {{doStop()}} to check if we have a cached {{Registry}} instance, and if we do, call {{UnicastRemoteObject.unexportObject(registry, true);}}

Some app servers have workarounds for this sort of leak (see "RMI targets" in Table 1 at [1]), but Weblogic doesn't seem to.

I'll also attach a screenshot of the memory analysis (more info at [2]).



[1] http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Fae%2Fctrb_memleakdetection.html

[2] http://www.yourkit.com/docs/kb/class_loaders.jsp

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira