You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Christian Steiner (Jira)" <ji...@apache.org> on 2019/11/20 09:13:00 UTC

[jira] [Created] (CXF-8161) Memory Leak/Thread Leak in JMSDestination & PollingMessageListenerContainer

Christian Steiner created CXF-8161:
--------------------------------------

             Summary: Memory Leak/Thread Leak in JMSDestination & PollingMessageListenerContainer
                 Key: CXF-8161
                 URL: https://issues.apache.org/jira/browse/CXF-8161
             Project: CXF
          Issue Type: Bug
          Components: JMS
    Affects Versions: 3.3.4
            Reporter: Christian Steiner


Hi,

when you create a JMS-Endpoint with concurrentConsumers > 1, PollingMessageListenerContainer starts a ThreadPoolExecutor running _concurrentConsumers_ instances of the class PollingMessageListenerContainer#Poller (or XAPoller)

If a exception from the jms-connection occurs, each Poller instance triggers JMSDestination#restartConnection, so JMSDestination creates _concurrentConsumers_ PollingMessageListenerContainer with _concurrentConsumers_*_concurrentConsumers_ Poller instances and threads and jms-consumers (for each Exception).

If you have _concurrentConsumers_ set to 10, first exception causes 100 threads, next exception 1000 etc.

Also is PollingMessageListenerContainer#stop not working, because in case of an Exception first the running-Flag in PollingMessageListenerContainer will be set to false. This causes old ThreadPools not to be cleaned up, the ThreadPools stay alive.

The Garbage Collector cann't clean up old instances of PollingMessageListenerContainer and Poller.

I think this Bug relates to CXF-7197

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)