Red Hat SummitFuse 6 is no longer supported
As of February 2025, Red Hat Fuse 6 is no longer supported. If you are using Fuse 6, please upgrade to Red Hat build of Apache Camel.このコンテンツは選択した言語では利用できません。
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 JMSCorrelationIDIf 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 theConsumer.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.
