Software AG Products 10.5 | Administering Integration Server | Configuring Integration Server for JMS Messaging | Working with JMS Connection Aliases | Creating a JMS Connection Alias | Configuring Automatic Retry when Sending JMS Messages Using the pub.jms:send Service | About Retrying the pub.jms:send Service when Software AG Universal Messaging Is the JMS Provider
 
About Retrying the pub.jms:send Service when Software AG Universal Messaging Is the JMS Provider
When the JMS connection alias is configured to retry the pub.jms:send service upon transient error and Universal Messaging is the JMS provider, Integration Server may make some changes to the local instance of the Universal Messaging connection factory to prevent or at least delay an exception from being thrown by Integration Server. Integration Server makes changes so that if Integration Server loses its connection to the Universal Messaging cluster, Integration Server does not throw an exception right away. Instead, Universal Messaging suppresses the exception for a period of time. During this time, Universal Messaging attempts to restore the cluster quorum. Concurrently, Integration Server attempts to re-establish a connection to Universal Messaging. During this delay, Integration Server is not notified of the exception and the JMS connection alias will not be stopped. However, JMS triggers that use the JMS connection alias will not receive any messages. Additionally, any pub.jms:send services that were in the midst of using the JMS connection alias to send a message will be retried based on the retry interval and retry count set for the JMS connection alias. If Universal Messaging cannot restore a cluster quorum, Integration Server throws the exception. At this point, any JMS trigger that uses the JMS connection alias will be stopped and any services that send JMS messages using the JMS connection alias will throw exceptions immediately. Integration Server then attempts to reconnect to Universal Messaging.
Integration Server makes changes to the Universal Messaging connection factory if the connection factory has a MaxReconAttempts property set to -1. (A value of -1 is the default and suggests that the MaxReconAttempts value has not been changed on Universal Messaging.) Integration Server makes the following changes to the local instance of the Universal Messaging connection factory:
*Sets ConxExceptionOnFailure to true.
*Sets MaxReconAttempts to 35.
*Sets ReconnectInterval to 2000 milliseconds.
Integration Server makes changes to the local instance of the Universal Messaging connection factory only. The ConnectionFactory will not be changed on the JNDI provider, which means that other clients that use the ConnectionFactory will not be impacted.
To prevent Integration Server from making changes to the local instance of the Universal Messaging connection factory, use the Universal Messaging Enterprise Manager to set the MaxReconAttempts property to a value greater than -1.