You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andriy Redko (Jira)" <ji...@apache.org> on 2019/12/15 02:24:00 UTC
[jira] [Resolved] (CXF-8161) Memory Leak/Thread Leak in
JMSDestination & PollingMessageListenerContainer
[ https://issues.apache.org/jira/browse/CXF-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andriy Redko resolved CXF-8161.
-------------------------------
Resolution: Fixed
> 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, 3.2.12
>
> 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)