Markus Dlugi created ARTEMIS-1759:
-------------------------------------
Summary: 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: 2.5.0, 1.0.0
Reporter: Markus Dlugi
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 to be 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
(v7.6.3#76005)
