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

[Ryan R. LaMothe (JIRA)]

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

Ryan R. LaMothe commented on JBESB-3583:
----------------------------------------

Two things:

1) This is happening with services which do not use JMS listeners.  The maxThreads setting is applied to all services and only one of them using a JMS listener.  If we leave the one service which is using JMS alone and turn all the other service maxThreads from 100 to 10, we get 10th of the threads in permanent use.

2) How do we use jms-jca-provider both per service and globally?

> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira