activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: InactivityMonitor - Creating too frequent threads
Date Thu, 20 Sep 2012 12:40:30 GMT
On Thu, Sep 20, 2012 at 2:23 PM, Hiram Chirino <> wrote:
> Was that impacting performance or memory usage in some measurable way?  I
> would assume you can't even measure the impact of starting/stopping a
> thread every 10 seconds.

No that is not measurable. As the tasks is background tasks, and they
do little work.

The point is the fact that a thread pool is created which wont re-use
any threads anyway.
And the 2nd point is that when people try out AMQ and kick its tires,
they can see from JMX stats
that it appears as AMQ is "leaking threads" because it keeps creating
new threads.

I did a new test with org.apache.activemq.UseDedicatedTaskRunner=true,
and also with 65 seconds on that affrementioned thread pool.
And this time I could run AMQ without any "thread leakings".

With Camel we have gone through great lengths to have all its thread
management visible for the end users
- Thread pools shown in JMX with full stats
- All thread names have Camel prefix + context id + unique counter
(pattern can be adjusted) to make thread names unique, as well end
users can much easier figure out what the thread does
- Ensure thread pools is shutdown when Camel shutdown
- Avoid excessive thread creation by having sensitive default settings
to ensure threads are reused
- Have DEBUG/TRACE logging when thread pools is created/terminated etc.

Anyway I would like with ActiveMQ Broker to have it run for a
extensive period of time in a JVM, and not have the JVM reported that
123456789 total threads created, and 1234567800 threads terminated.

> On Thu, Sep 20, 2012 at 7:28 AM, Claus Ibsen <> wrote:
>> Hi
>> 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
>> threads.
>> 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
>> Email:
>> Web:
>> Twitter: davsclaus
>> Blog:
>> Author of Camel in Action:
> --
> **
> *Hiram Chirino*
> *Engineering | Red Hat, Inc.*
> * <> | |*
> *skype: hiramchirino | twitter: @hiramchirino<>
> *
> *blog: Hiram Chirino's Bit Mojo <>*

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

View raw message