activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: InactivityMonitor - Creating too frequent threads
Date Wed, 28 Nov 2012 11:44:36 GMT
I think a jira is in order. +1 for clearly exposing the config options on
the thread pools and picking more sensible defaults.
Thread pool management has been neglected for some time, so we can benefit
from the camel experience here. Go Claus


On 20 September 2012 12:28, Claus Ibsen <claus.ibsen@gmail.com> 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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>



-- 
http://redhat.com
http://blog.garytully.com

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