activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: InactivityMonitor - Creating too frequent threads
Date Thu, 20 Sep 2012 12:23:22 GMT
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.

On Thu, Sep 20, 2012 at 7:28 AM, 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
>



-- 

**

*Hiram Chirino*

*Engineering | Red Hat, Inc.*

*hchirino@redhat.com <hchirino@redhat.com> | fusesource.com | redhat.com*

*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*

*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*

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