About Using Software AG Universal Messaging as the JMS Provider

Keep the Universal Messaging client libraries up to date. If you install a Universal Messaging fix that updates the client libraries, make sure to copy the updated Universal Messaging client library files to the Software AG_directory /common/lib directory used by Integration Server.

When using Integration Server with a higher version of Universal Messaging, Integration Server cannot use any features delivered in the higher version of Universal Messaging. Integration Server can use only the features that existed in the equivalent version of Universal Messaging.

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, ensure 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).

If Integration Server publishes documents to a Universal Messaging server on which the PauseServerPublishing configuration parameter is set to true, publishing fails with an nPublishPauseException. Integration Server handles the nPublishPauseException by proceeding as if the messaging connection alias is unavailable.

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.

The following table identifies the minimum values for the server configuration parameters that control polling intervals when Universal Messaging is the JMS provider.

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.