[
https://issues.apache.org/jira/browse/ARTEMIS-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic resolved ARTEMIS-1759.
--------------------------------------
Resolution: Fixed
> 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
> Assignee: Justin Bertram
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.45.0
>
> Attachments: artemis-cl-leak-example.zip, cl_leak_activemq.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
