[esb-issues] [JBoss JIRA] (JBESB-3583) MessageAwareListener Thread Pool does not clean up idle threads

[Kevin Conner (JIRA)]

    [ https://issues.jboss.org/browse/JBESB-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712268#comment-12712268 ] 

Kevin Conner commented on JBESB-3583:
-------------------------------------

JBESB-3785 added a dynamic thread pool into the MessageAwareListener, initial configuration has a minimum thread count of 1 and a maximum as specified in the jboss-esb.xml.

These configuration parameters are also exposed through the associated listener MBean allowing them to be changed at runtime (although not persisted).
                
> 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.8, 4.9
>         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/src/org/jboss/soa/esb/listeners/message/MessageAwareListener.java 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira