Tuning the JMS Transport

WSO2 ESB's Java Message Service (JMS) transport allows you to easily send and receive messages to queues and topics of any JMS service that implements the JMS specification. The following sections describes how you can tune the JMS transport of WSO2 ESB for better performance.

Increasing the maximum number of JMS proxies

If you create several JMS proxy services in WSO2 ESB, you will see a message similar to the following:

[2013-11-07 20:25:41,875]  WARN - JMSListener Polling tasks on destination : JMStoHTTPStockQuoteProxy18 of type queue for service JMStoHTTPStockQuoteProxy18 have not yet started after 3 seconds ..

This issue occurs when you do not have enough threads available to consume messages from JMS queues. The maximum number of concurrent consumers (that is, the number of JMS proxies) that can be deployed is limited by the base transport worker pool that is used by the JMS transport. You can configure the size of this worker pool using the system properties snd_t_core and snd_t_max. Note that increasing these values will also increase the memory consumption, becuase the worker pool will allocate more resources.

To adjust the values of these properties, you can modify the server startup script if you want to increase the available threads for all transports (requires more memory), or create a jms.properties file if you want to increase the available threads just for the JMS transport. Both approaches are described below.

To increase the threads for all transports:

1. Open the wso2server.sh or wso2server.bat file in your <ESB_HOME>/bin directory for editing.
2. Change the values of the properties as follows: 
   
   •  -Dsnd_t_core=200
   •  -Dsnd_t_max=250

To increase the threads for just the JMS transport:

1. Create a file named jms.properties with the following properties:

   • snd_t_core=200

   • snd_t_max=250

2. Create a directory called conf under your <ESB_HOME> directory and save the file in this directory.

Increasing the performance through concurrent consumers

You can increase the JMS listener performance through concurrent consumers.

Concurrent consumers is the minimum number of threads for message consuming. If there are more messages to be consumed while the running threads are busy, then additional threads are started until the total number of threads reaches the value of he maximum number of concurrent consumers (ie., MaxConcurrentConsumers). The maximum number of concurrent consumers (or the number of JMS proxies) that can be deployed is limited by the base transport worker pool that is used by the JMS transport. The size of this worker pool can be configured via the system property 'snd_t_core' and 'snd_t_max' as described above. The number of concurrent producers are generally limited by the Synapse core worker pool.

To increase the JMS listener performance

• Add the following parameters to the JMS listener configuration of the <ESB_HOME>/repository/conf/axis2/axis2.xml file.

  <parameter name="transport.jms.ConcurrentConsumers" locked="false">50</parameter> 
  <parameter name="transport.jms.MaxConcurrentConsumers" locked="false">50</parameter>

Increasing the performance through caching in the JMS listener

Another way of improving the JMS transport performance is to enable caching.

To enable caching in the JMS listener

• Add the following parameter to the JMS listener configuration of the <ESB_HOME>/repository/conf/axis2/axis2.xml file.

  <parameter name="transport.jms.CacheLevel">consumer</parameter>

  The possible values for the cache level are none, auto, connection, session and consumer. Out of the possible values, consumer is the highest level that provides maximum performance.

After adding concurrency consumers and cache level, your complete configuration would be as follows:

<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener"> 
....
<parameter name="myQueueConnectionFactory" locked="false"> 
<parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter> 
<parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter> 
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter> 
<parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter> 
<parameter name="transport.jms.ConcurrentConsumers" locked="false">50</parameter> 
<parameter name="transport.jms.MaxConcurrentConsumers" locked="false">50</parameter> 
<parameter name="transport.jms.CacheLevel">consumer</parameter> 
</parameter>
….
</transportReceiver>

Increasing the performance through caching in the JMS sender

To enable caching in the JMS sender

• Add the following parameter to the JMS sender configuration of the <ESB_HOME>/repository/conf/axis2/axis2.xml file.

  <parameter name="transport.jms.CacheLevel">producer</parameter>

  The possible values for the cache level are none, auto, connection, session and producer. Out of the possible values, producer is the highest level that provides maximum performance.

Using ClientApiNonBlocking when sending messages via JMS

By default, Axis2 spawns a new thread to handle each outgoing message. To change this behavior, you need to remove the ClientApiNonBlocking property from the message.

To remove the ClientApiNonBlocking property

• Add the following parameter to the configuration

  <property name="ClientApiNonBlocking" action="remove" scope="axis2"/>