[
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
