[CXF-8161] Memory Leak/Thread Leak in JMSDestination & PollingMessageListenerContainer

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.2.11, 3.3.4
• Fix Version/s: 3.3.5, 3.2.12, 3.4.0
• Component/s: JMS
• Estimated Complexity: Unknown
• Assignee: Unassigned
• Reporter: Christian Steiner
• Created: 20/Nov/19 09:12
• Updated: 17/Apr/20 15:24
• Resolved: 15/Dec/19 02:23

Description

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

 

 

Issue Links

• causes: CXF-8259 Blocked thread of JMS transport during jboss shutdown
• links to: GitHub Pull Request #603
• links to: GitHub Pull Request #614