camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Resolved] (CAMEL-5907) Camel leaks memory on undeploy / redeploy in app server when JMX enabled and createConnector = true
Date Wed, 02 Jan 2013 07:12:13 GMT


Claus Ibsen resolved CAMEL-5907.

       Resolution: Fixed
    Fix Version/s: 2.11.0

Thanks for the patch.
> Camel leaks memory on undeploy / redeploy in app server when JMX enabled and createConnector
= true
> ---------------------------------------------------------------------------------------------------
>                 Key: CAMEL-5907
>                 URL:
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jmx
>    Affects Versions: 2.10.0
>            Reporter: Daniel Gredler
>            Assignee: Willem Jiang
>            Priority: Minor
>             Fix For: 2.9.6, 2.10.4, 2.11.0
>         Attachments: camel-5907.patch, 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}}"
>         <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]
> [2]

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:

View raw message