[
https://issues.apache.org/jira/browse/CXF-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8161:
------------------------------
Affects Version/s: 3.2.11
> 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.2.11, 3.3.4
> Reporter: Christian Steiner
> Priority: Major
> Fix For: 3.4.0, 3.3.5
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
