Hi Andy Yeah sure create a JIRA ticket.
When I looked into this initially I didn't want to "change" default and cause any side-effects. As I am still new in some areas of ActiveMQ source code. I think I have seen others have a + 1.5 x as their thread timeout default value for scheduled tasks. So if the task runs for 30 sec, then it has a timeout of + 45 sec = 75 sec. Allowing people to configure this would at least allow people to go back to the old behavior in case for som "odd" reason that worked better. Another reason why I would like to avoid this thread creation / termination all the time. Is that I have seen platforms crash the JVM due OOME when allocating/creating the thread. Anyway a JIRA and pactches is of course as usually always welcome at ASF projects. On Wed, Nov 28, 2012 at 11:02 AM, AndyG <[email protected]> wrote: > I agree. I am using ActiveMQ within OpenEJB and under our normal load I have > about 140 threads alive. Just about the only thread deaths I have are the > 'ActiveMQ InactivityMonitor Worker' and 'ActiveMQ BrokerService[name] > Task-[count]. > > I tend to wait for a stable snapshot and then change the pool value to 2 > minutes in the AbstractInactivityMonitor.java (default 10 seconds) and > TaskRunnerFactory.java (default 30 seconds) and so far I have not seen the > thread count creep up due to the fact that the pools are unbounded. > > It would make life easier if these values were a configuration option or at > least taken from a System property. > > Maybe a JIRA is in order? > > Andy. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/InactivityMonitor-Creating-too-frequent-threads-tp4656752p4659873.html > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- 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
