camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Gredler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-5907) Camel leaks memory on undeploy / redeploy in app server when JMX enabled and createConnector = true
Date Sat, 22 Dec 2012 02:59:12 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Gredler updated CAMEL-5907:
----------------------------------

    Attachment: leak.png
    
> 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

Mime
View raw message