Configuring JMS in WAS could be quite confusing due to large number of settings and configuration resources (destination, queue/topic, connection factory, activation spec).
One of the most confusing aspects of this configuration is the quality of service (QOS) settings that deal with message reliability.
These settings can be configured using SIB destination:
And/or connection factory:
The reliability is also influenced by the JMS APIs used by the application code ( MessageProducer.setDeliveryMode, MessageProducer.send).
Here’s how the message reliability is determined:
* Message producer sends a message with the requested delivery mode. Note that the PERSISTENT mode is the default.
* If the destination for the message is set to allow producers to override reliability, the reliability setting defined on the connection factory for the given delivery mode is used. However, if the connection factory’s setting is “As bus destination”, the default reliability setting of the destination is used.
* If the reliability can not be overridden, the default reliability setting of the destination is used.
* If the resulted reliability level exceeds the maximum reliability setting for the destination, the exception is thrown or the message is routed to the error destination.
The takeaway is that, by default, the reliability settings on the destination are ignored.
Here are the two widespread misconceptions about JMS reliability:
* Default settings provide the best QOS/highest reliability. This is not the case. Connection factory is configured with “Reliable Persistent” by default which is a notch below the highest “Assured Persistent”. “Reliable Persistent” could result in lost messages and dupes as the messages are persisted asynchronously.
* Non-persistent reliability mode means that messages are never saved to the message store and kept in memory. This is not the case. WAS saves non-persistent messages to the message store when the queue depth becomes too high.
When choosing reliability, try to determine the minimally acceptable reliability level for the application. A non-persistent reliability level will always be faster than the persistent one. Be especially wary of the “top of the line” “assured delivery” level. In this mode WAS synchronously saves each and every message to the message store. If you’re using a database to host the message store, this would result in a database hit for every message delivered to the destination.
Have a question about WebSphere JMS tuning/configuration? Please comment on this post. You may also be interested in other WAS-related articles on this site.
Need help with WebSphere or JMS? Interested in performance tuning or in implementing fully automated configuration management for your middleware? Consider our WAS automation framework and our consulting services.