About Using Software AG Universal Messaging as the JMS Provider

When using Universal Messaging as the JMS provider, the JMS client can use synchronous or asynchronous publishing. With synchronous publishing, the JMS client sends messages to Universal Messaging one at a time. The JMS client receives a response indicating a successful send only after the message has been delivered to Universal Messaging. With asynchronous publishing, the JMS messages are placed in a buffer and then sent to Universal Messaging in batches. However, the JMS client can receive a response indicating a successful send before the message is actually delivered to Universal Messaging. Asynchronous publishing is faster than synchronous publishing, but messages can be lost in the event the connection to Universal Messaging fails or Integration Server becomes unavailable. The default for a JMS client using Universal Messaging as the JMS provider is asynchronous publishing. This default applies to all messages regardless of a persistent or non-persistent delivery mode. However, to ensure delivery of a persistent message, Integration Server always uses synchronous publishing to send a persistent JMS message to Universal Messaging.

If you are using Universal Messaging as the JMS provider and you want to use durable subscribers, make sure to select the “Shared Durable” option when creating a ConnectionFactory or TopicConnectionFactory using Universal Messaging Enterprise Manager. For example, when creating a ConnectionFactory, select the option named “Connection Factory (Shared Durable)”.

When an Integration Server JMS connection alias is connected to a cluster of Universal Messaging realm servers and the master realm server in the cluster goes down, Integration Server stops the alias. This causes all JMS triggers associated with the alias to stop, and all JMS sending services to fail with a ResourceUnavailableException. The alias automatically reconnects to the cluster if and when the cluster is able to reconcile itself (that is, the cluster is able to reelect a new master realm server).

Integration Server enforces minimum values for the server configuration properties that control the polling intervals for JMS triggers when Universal Messaging is the JMS provider. The default values for these parameters are not optimal when connecting to Universal Messaging. Lower polling intervals, including the default values, can result in high CPU utilization on the Universal Messaging server and do not provide a performance benefit when working with Universal Messaging.

Parameter

Minimum value used with Universal Messaging

watt.server.jms.trigger.concurrent.
primaryThread.pollingInterval

3000 milliseconds

watt.server.jms.trigger.concurrent.
secondaryThread.pollingInterval

3000 milliseconds if the concurrent JMS trigger does not use a join

10 milliseconds if the concurrent JMS trigger uses a join

watt.server.jms.trigger.serial.
primaryThread.pollingInterval

3000 milliseconds

Note:

If the serial JMS trigger uses a join, Integration Server uses a secondary polling interval which is set to 10 milliseconds. Note that the secondary polling interval is not configurable for a serial JMS trigger.

You can increase the polling intervals by changing the server configuration parameters. Keep in mind that the values you specify will be used with all JMS providers. Integration Server only enforces a minimum when connecting to Universal Messaging.

JMS triggers that use joins might affect the CPU utilization for Universal Messaging even with the minimum values mentioned above. This is because the secondary polling interval is low (10 milliseconds). The secondary polling interval needs to be low so that the JMS trigger can quickly retrieve messages from the different destinations. To reduce the impact on Universal Messaging, consider one of the following approaches:

For a concurrent JMS trigger, configure the JMS connection alias used by the trigger to use multiple connections and then set the JMS trigger Connection count property to a value that is evenly divisible by the number of destinations. For example, if a JMS trigger retrieves messages from two destinations, set Connection count to 2, 4, 6, 8, and so on. If the JMS trigger retrieves messages from three destinations, set Connection count to 3, 6, 9, and so on.

For a serial or concurrent JMS trigger, instead of using a join for the JMS trigger, use a Universal Messaging channel join to gather messages from different destinations into a single destination on the Universal Messaging server.

A Universal Messaging client, such as Integration Server caches some information about destination objects. Integration Server, keeps this information in the client store cache. However, when particular queue or channel properties (such as Time to Live and Maximum Number of Events) are changed using Universal Messaging Enterprise Manager,Universal Messagingserver creates a new destination object for the channel or queue. However, Integration Server is not aware of the new destination object for the channel or queue and continues to use the obsolete cached destination object. Consequently, sending messages to the channel or queue fails because Integration Server cannot locate the destination. JMS triggers cannot receive messages from the channel or queue fails for the same reason. To resolve this issue and allow Integration Server to connect to the destination, you must restart the JMS connection alias by first disabling the alias and then enabling it.