[
https://issues.apache.org/jira/browse/ARTEMIS-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17420661#comment-17420661
]
Antoni Reus commented on ARTEMIS-1759:
--------------------------------------
Same problem in JBoss EAP 7.2. In our case ServerLocatorImpl.traceException
maintains a reference to an application EJB.
> ClassLoader leaks in Artemis Core Client and JMS Client
> -------------------------------------------------------
>
> Key: ARTEMIS-1759
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1759
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 1.0.0, 2.5.0
> Reporter: Markus Dlugi
> Priority: Major
> Attachments: artemis-cl-leak-example.zip, cl_leak_activemq.png
>
>
> There are multiple classloader leaks which are caused by the following fields:
> *
> org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.traceException
> *
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createTrace
> * org.apache.activemq.artemis.jms.client.ActiveMQConnection.creationStack
> All of these fields contain Exceptions which are created during instantiation
> of these classes and later on used for logging purposes. However, the
> exceptions and their stack traces can also contain references to application
> objects, which may then prevent application classloaders from being garbage
> collected, leading to OutOfMemoryErrors in the worst case.
> Attached is a small example project which reproduces the problem. When
> deployed on WildFly 12, a startup bean sends a message to a message-driven
> bean, which in turn initializes the three aforementioned classes. When the
> example project is undeployed, a heap dump of the application server will
> show that the aforementioned fields still have a reference to the
> message-driven bean, which in turn prevents the deployment's classloader from
> being garbage collected.
> Also attached is a screenshot of the Eclipse Memory Analyzer demonstrating
> two of the leaks after the example project has been undeployed.
> While I'm not sure how to best avoid this problem apart from removing the
> traces altogether, I think that more informative logging should not lead to
> memory leaks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
