When come to SOA (Service Oriented Architecture) integration patterns "reliable message delivery" and "message throttling" are very common. Typical way of achieving this is using Enterprise Service Bus with a JMS provider. WSO2 ESB and WSO2 MB can be easily configured together to achieve this.
Please refer post here to understand how it works.
Once the setup is done, you need to consider following factors in order to fine tune it for better and stable deployment in the long run.
Please refer post here to understand how it works.
Once the setup is done, you need to consider following factors in order to fine tune it for better and stable deployment in the long run.
Make Message sending faster
ESB can use caching connections, sessions and message producer when sending JMS messages. For maximum performance of JMS message sending use caching level "producer". Please refer appendix for detail. When configuring WSO2 ESB with WSO2 MB this is reccomended. You can configure it in [ESB_HOME]/repository/conf/axis2/axis2.xml file or at JMS endpoint
<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender">
<parameter name="default" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
<parameter name="transport.jms.CacheLevel">producer</parameter>
</parameter>
</transportSender>
<endpoint>
<address uri="jms:/jndiQueueName?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&java.naming.factory.initial=org.wso2.andes.jndi.PropertiesFileInitialContextFactory&java.naming.provider.url=repository/conf/jndi.properties&transport.jms.CacheLevel=producer&transport.jms.DestinationType=queue"/>
</endpoint>
Make Message Receiving Faster
- Caching levels described for sending JMS messages are valid for message receiving as well. Thus use caching level "consumer" for maximum performance for receiving messages. Another thing is when configuring WSO2 ESB with WSO2 MB this is a MUST.
-
If you define this at axis2.xml, it will be applied to all JMS proxies created in ESB.
<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener"> <parameter name="myQueueConnectionFactory" locked="false"> <parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter> <parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter> <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter> <parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter> <parameter name="transport.jms.CacheLevel">consumer</parameter> </parameter> </transportReceiver>
Also you can define this at proxy level as well. Then it is applied to that proxy only.<proxy name="JMSQueueListenerProxy" transports="jms"> <target> <inSequence> <property action="set" name="OUT_ONLY" value="true"/> <log level="full"/> <drop/> </inSequence> <outSequence> </outSequence> </target> <parameter name="transport.jms.ContentType"> <rules> <jmsProperty>contentType</jmsProperty> <default>application/xml</default> </rules> </parameter> <parameter name="transport.jms.ConnectionFactory">myQueueConnectionFactory</parameter> <parameter name="transport.jms.Destination">myQueue</parameter> <parameter name="transport.jms.DestinationType">queue</parameter> <parameter name="transport.jms.CacheLevel">consumer</parameter> </proxy>
- Tune JMS thread pools according to the concurrency needed. If you are having a lot of JMS listener proxies, or lot of JMS operations you need to increase following values. Edit wso2server.sh file (or wso2server.bat for Windows) inside [ESB_HOME]/bin folder with following parameters.
-Dsnd_t_core=200 \ -Dsnd_t_max=250 \
Note that default value for this is 100. This means ESB can open 100 maximum concurrent subscribers only.
- If you are subscribing messages from a queue, you can start multiple consumer threads which work in parallel to receive messages. This will increase the performance. But be careful ESB has enough memory/cpu to process the message load. Also you might need to consider thread pool parameters described above as well. You cannot use this mechanism to speed up message consuming from a topic, because it will cause messages to be duplicated (Broker sees them as individual subscribers).
- Set concurrent consumers to start
<parameter name="transport.jms.ConcurrentConsumers" locked="false">10</parameter>
- Set a maximum number of consumers it can grow
<parameter name="transport.jms.MaxConcurrentConsumers" locked="false">10</parameter>
Appendix
By default when sending messages WSO2 ESB creates a new connection for every message.
This adds a large overhead for the system as it creates a new connection, session and a sender for every message it sends and close them. To prevent that we can use caching at ESB side.
Connection Caching
This is the lowest level of caching. Here JMS connection is cached and new only sessions and senders are created per message.
Session Caching
Here JMS connection and session are cached. Producer objects are created every time a message is sent.
Producer Caching
This is the maximum level of caching. All connection, session, and producer are cached. All messages are sent to the broker using that cached JMS producer instance. Nothing is initialized per message.
