[
https://issues.apache.org/jira/browse/AMQ-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037111#comment-13037111
]
Minh Do commented on AMQ-3214:
------------------------------
Hi Timothy,
We actually had this issue in a few different enviroments here running ActiveMQ
server or ActiveMQ client.
In my previous company, they opted out to purchase SonicMQ after deploying
ActiveMQ server to production and having to restart ActiveMQ almost every week
with a noticeable slow-down day after day.
I would not say that it is JDK's bug. The way ThreadPoolExecutor being used in
that InactivityMonitor is the problem.
I can repeat this every time. Otherwise, could you please explain why there
are so many InactivityMonitor threads in my attached image? I was using
YourKit to do the profiling.
> "InactivityMonitor Async Task" threads leaking
> ----------------------------------------------
>
> Key: AMQ-3214
> URL: https://issues.apache.org/jira/browse/AMQ-3214
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client, Transport
> Reporter: Minh Do
> Priority: Critical
> Fix For: 5.6.0
>
> Attachments: threadleak.png
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> -Have a multi-thread consumers running to consumer messages
> -Have Connection to have these :
> ActiveMQConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory(brokerUrl);
> connectionFactory.setUseAsyncSend(false);
> connectionFactory.setDispatchAsync(false);
> connectionFactory.setAlwaysSessionAsync(false);
> connectionFactory.setAlwaysSyncSend(true);
> -Run the consumers for several hours and profile it
> -You will see there are threads with the name "InactivityMonitor Async Task"
> being spawning continuously
> This will cause the entire consumer system to slow down eventually due to
> thread context switching.
> Suggestion to fix: we should not put a limit on the number of
> "InactivityMonitor Async Task" threads to be Max Integer. There is a bug in
> Java lib that
> it will not stop a thread after a given idle time-to-live. We could fix this
> in the file InactivityMonitor.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira