[
https://issues.apache.org/jira/browse/ARTEMIS-1759?focusedWorklogId=991803&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-991803
]
ASF GitHub Bot logged work on ARTEMIS-1759:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 14/Nov/25 19:49
Start Date: 14/Nov/25 19:49
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #6070:
URL: https://github.com/apache/activemq-artemis/pull/6070
Remove fields that hold stack-traces in a few classes. These are mostly
unused and when they are used it is only for logging. The upside of having
additional logging is not worth the risk of leaks and eventual OOME.
Issue Time Tracking
-------------------
Worklog Id: (was: 991803)
Remaining Estimate: 0h
Time Spent: 10m
> 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
> Labels: pull-request-available
> Attachments: artemis-cl-leak-example.zip, cl_leak_activemq.png
>
> Time Spent: 10m
> 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
