Let’s say we have a service picking messages off a JMS queue. We may want to throttle the number of messages consumed or increase the service’s message throughput. We could do this by specifying the number of threads retrieving messages from the queue. Alas, you are faced with two options when doing this in Mule 3:
1. Set the numberOfConsumers attribute on the JMS connector
2. Set the maxThreadsActive attribute on the JMS connector’s receiver-threading-profile element
<jms:activemq-connector name="jmsConnector" numberOfConsumers="15" brokerURL="vm://localhost"> <receiver-threading-profile maxThreadsActive="15"/> </jms:activemq-connector>
Which will you configure? Well, it depends whether you are using a polling or an event-driven consumer. A polling consumer is employed by Mule whenever your JMS queue is participating in an XA transaction. On the other hand, a non-transactional JMS queue means that an event-driven consumer is used.
In both cases, numberOfConsumers determines the no. of threads consuming messages from the queue. BUT in the transactional scenario, the numberOfConsumers threads are borrowed from the receiver thread pool.
How do you set the receiver thread pool size? Yes, you guessed it: setting the maxThreadsActive attribute in the receiver-threading-profile element. To summarise, ensure that maxThreadsActive setting is at least as big as numberOfConsumers. For example, having numberOfConsumers set to 24 but leaving maxThreadsActive set to the default (i.e., 16) would result only 16 threads consuming messages from the queue since no more threads can be borrowed from the receiver thread pool.
In the non-transactional scenario, the answer is simpler. Thread creation is taken care of by the JMS client library. This means that receiver-threading-profile’s maxThreadsActive doesn’t have any impact with regards to message consumption.