activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject InactivityMonitor - Creating too frequent threads
Date Thu, 20 Sep 2012 11:28:21 GMT

I ran a test which pushes 50 x 20.000 request/reply messages over TCP
using Camel as Client and AMQ as broker (non persistent).
As part of the TCP transport there is inactivity monitoring and I
noticed from jvisualvm that it seems to be creating to many new

See the dead screenshot attached.

I noticed in the source code that the thread pool it uses for the
tasks, have a 10 sec idle timeout.
In this class: org.apache.activemq.transport.AbstractInactivityMonitor
        ThreadPoolExecutor exec = new ThreadPoolExecutor(0,
Integer.MAX_VALUE, 10, TimeUnit.SECONDS, new
SynchronousQueue<Runnable>(), factory);

But the tasks for periodic read/write check is scheduled to run once
every 30 sec by default
    private static long DEFAULT_CHECK_TIME_MILLS = 30000;

The read and write checker is based on a java.util.Timer that runs
evert that 30 sec period. So that takes up 1 thread each, and this
thread is never expired.

So that gives me the assumption, that every 30 sec a read and write
task is fired. And depending on conditions either of them my execute a
new task on that thread pool I mentioned first. If a task is run, it
may run for a little while doing what it does, and the task exists.
And the thread returns to the pool.

But since the pool has 10 sec idle timeout, and the core pool size is
zero. Then that allows all threads to terminate if they are not in
use. And as there is about 30 sec until the next timer triggers. Then
its very likely that this thread will not be re-used the next time.
And therefore the thread is terminated, and a new thread has to be
created on next time.

I captured this in a screenshot. See the dead attached file. It shows
all the terminated threads from jvsualvm running that test above. And
yes the test is running and processing a lot of messages. So there is
activity over TCP.

So what I did was to adjust the source code to set the idel timeout of
the thread pool to be higher. For example 60 seconds
        ThreadPoolExecutor exec = new ThreadPoolExecutor(0,
Integer.MAX_VALUE, 60, TimeUnit.SECONDS, new
SynchronousQueue<Runnable>(), factory);

And re-ran the tests. I have attached screenshots of that, they are
naming total2 and dead2. Notice that now the total number of threads
created is lower. And as well there is no inactive monitor async task
threads which has died.

Claus Ibsen
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: davsclaus
Author of Camel in Action:

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message