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

["Claus Ibsen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538755#comment-13538755 ] 

Claus Ibsen commented on CAMEL-5907:
------------------------------------

Thanks for reporting.

Would you be able to work on a patch with your suggested fix?

There is a bit information about how to create and contribute patches at:
http://camel.apache.org/contributing.html
                
> 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
>         Attachments: leak.png
>
>
> 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