Red Hat Training

A Red Hat training course is available for Red Hat Fuse

14.3. Optimizing Client-Side JMS Performance

Overview

Two major settings affect the JMS performance of clients: pooling and synchronous receives.

Pooling

On the client side, CXF creates a new JMS session and JMS producer for each message. This is so because neither session nor producer objects are thread safe. Creating a producer is especially time intensive because it requires communicating with the server.
Pooling connection factories improves performance by caching the connection, session, and producer.
For ActiveMQ, configuring pooling is simple; for example: 
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.pool.PooledConnectionFactory;
 
ConnectionFactory cf = new ActiveMQConnectionFactory("tcp://localhost:61616");
PooledConnectionFactory pcf = new PooledConnectionFactory();
 
//Set expiry timeout because the default (0) prevents reconnection on failure
pcf.setExpiryTimeout(5000); 
pcf.setConnectionFactory(cf);
 
JMSConfiguration jmsConfig = new JMSConfiguration();
 
jmsConfig.setConnectionFactory(pdf);
For more information on pooling, see "Appendix A Optimizing Performance of JMS Single- and Multiple-Resource Transactions" in the Red Hat JBoss Fuse Transaction Guide

Avoiding synchronous receives

For request/reply exchanges, the JMS transport sends a request and then waits for a reply. Whenever possible, request/reply messaging is implemented asynchronously using a JMS MessageListener.
However, CXF must use a synchronous Consumer.receive() method when it needs to share queues between endpoints. This scenario requires the MessageListener to use a message selector to filter the messages. The message selector must be known in advance, so the MessageListener is opened only once.
Two cases in which the message selector cannot be known in advance should be avoided:
  • When JMSMessageID is used as the JMSCorrelationID
    If the JMS properties useConduitIdSelector and conduitSelectorPrefix are not set on the JMS transport, the client does not set a JMSCorrelationId. This causes the server to use the JMSMessageId of the request message as the JMSCorrelationId. As JMSMessageID cannot be known in advance, the client has to use a synchronous Consumer.receive() method.
    Note that you must use the Consumer.receive() method with IBM JMS endpoints (their default).
  • The user sets the JMStype in the request message and then sets a custom JMSCorrelationID.
    Again, as the custom JMSCorrelationID cannot be known in advance, the client has to use a synchronous Consumer.receive() method.
So the general rule is to avoid using settings that require using a synchronous receive.