MessageAwareListener Thread Pool does not clean up idle threads --------------------------------------------------------------- Key: JBESB-3583 URL: https://issues.jboss.org/browse/JBESB-3583 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.9, 4.8 Environment: JBoss 5.1.0.GA with ESB 4.8 running on Win 7 64-bit, Mac OS X, and RHEL 5.5 all running MySQL 5.1.5x Java 1.6.0_20 and Java 1.6.0_24 Reporter: Peter Nordquist In the MessageAwareListener at http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s... on line 232 a fixed thread pool is allocated. This causes the possibility of having at most maxThreads around for the life of the App server even if the service is not being used. Behind the scenes the Executors.newFixedThreadPool(_maxThreads) creates a java.util.concurrent.ThreadPoolExecutor with a core pool size of maxThreads and a max pool size of maxThreads and 0L for the keep alive time and giving it a new LinkedBlockingQueue<Runnable>() for the queue. This Executor will not precreate the threads but as calls happen it will allocate threads as needed and keep them around forever since the core pool size is the same as the max pool size. If there are a large number of services defined with high values for maxThreads a 'java.lang.OutOfMemoryError: unable to create new native thread' exception will occur. I suggest that you fix this by actually instantiating a java.util.concurrent.ThreadPoolExecutor with a core pool size of something other than maxThreads (possibly 0 since it would then destroy all threads when they are not needed) a max pool size of the passed in maxThreads and a keep alive time of your choice. We are currently using 4.8 but are evaluating 4.9 and see the same problem in that version. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira