About Using Software AG Universal Messaging as the JMS Provider
Keep the following points in mind when using Universal Messaging as the JMS provider:
![*](chapterTOC_bullet.png)
When using
Universal Messaging, if the version of
Universal Messaging is equivalent to or higher than the version of
Integration Server, you do not need to add any client libraries to the
Integration Server classpath.
![*](chapterTOC_bullet.png)
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.
![*](chapterTOC_bullet.png)
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.
Integration Server uses synchronous publishing as the default when publishing persistent messages to
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.
![*](chapterTOC_bullet.png)
Message priority is not supported when
Universal Messaging is the JMS provider. Any priority assigned to a JMS message sent to
Universal Messaging will be ignored.
![*](chapterTOC_bullet.png)
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).
![*](chapterTOC_bullet.png)
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).
![*](chapterTOC_bullet.png)
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.
![*](chapterTOC_bullet.png)
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:
![*](chapterTOC_bullet.png)
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.
![*](chapterTOC_bullet.png)
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.
![*](chapterTOC_bullet.png)
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.