5.6. JMS Integration or Provider
jca-jboss-beans.xmlin the directory
JBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy. Note that the
minimalconfiguration does not contain the JCA container.
<!-- THREAD POOL --> <bean name="WorkManagerThreadPool" class="org.jboss.util.threadpool.BasicThreadPool"> <!-- Expose via JMX --> <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.jca:service=WorkManagerThreadPool", exposedInterface=org.jboss.util.threadpool.BasicThreadPoolMBean.class)</annotation> <!-- The name that appears in thread names --> <property name="name">WorkManager</property> <!-- The maximum amount of work in the queue --> <property name="maximumQueueSize">1024</property> <!-- The maximum number of active threads --> <property name="maximumPoolSize">100</property> <!-- How long to keep threads alive after their last work (default one minute) --> <property name="keepAliveTime">60000</property> </bean>
maximumPoolSizeparameter specifies the number of threads in the thread pool for use by the JMS provider. The default size is 100, which may or may not be appropriate. If message driven beans are used in the application, make sure that there are enough threads in the thread pool to handle the maximum number of sessions. If only one message driven bean is used, ensure that the thread pool is at least the size of the number of sessions for that one bean. If there are many different message driven beans, the calculations are more complex.
Figure 5.4. JMX Console Thread Pool Statistics
maximumQueueSizeparameter specifies how many requests will wait for a thread to become available before an exception is thrown and processing is aborted. The default value is 1024, which is a safe value. You may want to fail fast, versus wait for an extended period of time, or have more than 1024 requests backed up before failing. Setting this parameter to a lower value means you'll know earlier of exceptions but at the expense of application uptime. It's recommended to leave it at the default value as it provides greater reliability. If a request is waiting in the queue it's because there are none available in the pool. While sizing the pool, monitor the number of requests waiting in the queue to confirm whether or not the pool is too small.