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 <[email protected]> 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: [email protected] > 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.* *[email protected] <[email protected]> | fusesource.com | redhat.com* *skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino> * *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
