info@yenlo.com
eng
Menu
WSO2 Enterprise Integrator 4 min

Tuning of JMS Transport with WSO2 Enterprise Integrator

omar khalid
Omer Khalid
Integration Consultant
jms

Products: Following configuration can be applied from EI 6.2.0 to EI 6.6.0.

Have you ever been on a long road trip, driving hundreds of miles across Europe through different beautiful cities enjoying the culture and the food? If so, what is the first thing you do once you are back, after taking a long weekend to rest of-course? You might take your car to a garage to do some checkups of engine oil or batteries. You probably want to make sure that everything is ok with the car, and it is still 100 percent safe to drive. Likewise, when we play any musical instrument long enough, at some point it also needs a good tuning so that it can keep making that beautiful sound that it is supposed to do.

Similarly, when we talk about IT Systems and Products, they need regular maintenance as well. And if you don’t do it Proactively, you will only know about it when it is too late. Usually, as human beings, we are flawed to never think too much about the stuff that are running smoothly and only spring into action when something gets broken down. But as a wise man once said:

“ The time to repair the roof is when the sun is shining”      

John. F. Kenedy (1917-1963)

What is JMS?

JMS stands for Java Message Service. The JMS within WSO2 EI enables you to easily send and receive messages to queues and topics of any JMS Service that implements the JMS Specification. With JMS you can publish messages to the queues and topics on any message broker. With the EI the most used message brokers are ActiveMQ, RabbitMQ and WSO2’s own Message Broker.

With complex integration Scenarios, you often need to implement the Guaranteed Message Delivery Pattern where you need to make sure that the message is not lost. One way of implementing this pattern is by using the Queues and Topics. This way messages can be rolled back in case of a connection failure or any other issue.

With the increasing need of implementing services that guarantee reliable messaging exchange, the number of JMS based services is also increasing. After a while when there are too many services using JMS Transport, we need to fine-tune it a bit to cater to our needs. The default settings, just won’t cut it.

How to increase the number of JMS Threads?

There are many ways to increase the capacity of EI to handle more JMS based connections. Here we will discuss only one: how to increase the number of JMS Threads. This configuration will give you enough JMS Threads available to consume the messages from the queues. The maximum number of JMS Proxies that can run concurrently gets decided by the values assigned to these properties.

You can create a file name jms.properties in <EI_HOME>/conf folder of the product.

  • lst_t_core=200
  • lst_t_max=250
  • snd_t_core=200
  • snd_t_max=250

Default value of these attributes are just 20. If you will not define a value explicitly, then the default values will be assigned automatically. WSO2 has provided a simple method for you to calculate what to put it in these properties.

  • lst_t_core >  Total number of consumers + 20
  • lst_t_core < lst_t_max
  • snd_tsnd_t_core > Total number of consumers + 20
  • snd_t_core < snd_t_max

You can calculate the Total number of consumers by the following formula

Total number of consumers = transport.jms.MaxConcurrentConsumers * Number of JMS proxies

(you can find the value of transport.jms.MaxConcurrentConsumers in the <EI_HOME>/conf/axis2/axis2.xml under JMS Listener transport configuration. If not present, you can define this value there.)

After doing all these settings, you need to restart the EI and then the settings will take effect.

Conclusion

JMS based solutions are becoming more common due to the ease of implementation of Guaranteed Message Delivery and Message Roll Back Enterprise Integration Patterns. Within the WSO2 Enterprise Integrator, to use the failover mechanism of JMS based services, we need to use blocking mode in the Call mediator. This way, we can preserve the message and roll it back if any connection attempt fails with the backend system.

By default, the limit of these JMS connections is very low in the Product Settings. This blog highlights couple of steps by which you can enhance the performance of JMS proxy services by increasing the underlying number of threads that are assigned to this cause. It is better to do these settings proactively or before a production rollout to avoid any errors.

Too Confusing?  Try Connext or Connext Go

If you want to ignore the hassle of going through these configurations and taking care of this stuff yourself, then you can always explore our Platform as a service product CONNEXT. When you use CONNEXT, Yenlo takes care of all the settings and configurations. You don’t have to do anything. Just sit back and relax and keep building on the Integrations.:

eng
Close