Running Business Processes and Composite Applications : webMethods Integration Server Administrator’s Guide : 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
Configuring Automatic Retry when Sending JMS Messages Using the pub.jms:send Service
 
About Retrying the pub.jms:send Service when webMethods Universal Messaging Is the JMS Provider
You can configure a JMS connection alias so that Integration Server automatically retries a pub.jms:send service that uses the JMS connection alias if the service fails because of a transient error. To configure automatic retry for instances of the pub.jms:send service that use a particular JMS connection alias to send messages to the JMS provider, you specify the following for the alias:
*Maximum number of retry attempts.The Max Retry Count field determines the maximum number of times that Integration Server will retry a particular pub.jms:send service. A Max Retry Count of 0 indicates that automatic retry is disabled for the JMS connection alias.
*Interval between retry attempts. The Retry Interval field determines the number of milliseconds that Integration Server waits between retry attempts. The default interval is 1000 milliseconds (1 second).
The JMS connection alias must also meet the following criteria for a pub.jms:send service that uses the alias to be retried after a transient error:
*The JMS connection alias must be enabled.
*The JMS connection alias must have a transaction type of NO_TRANSACTION. Integration Server will not retry a pub.jms:send service that is executed as part of a transaction.
*If the JMS connection alias specifies the Broker as the JMS provider, the JMS connection alias must not use a cluster connection factory to which the multisend guaranteed policy is applied.
The following table describes the retry process that Integration Server uses the pub.jms:send service fails because of a transient error and the JMS connection alias is configured for retry.
Stage
Description
1
Execution of the pub.jms:send service fails because of a transient error.
2
Integration Server waits the length of the retry interval.
Note:  
If Integration Server begins to shut down while waiting to retry, Integration Server interrupts the waiting period and retries the service.
Note:  
If the JMS connection alias becomes disabled while Integration Server waits to retry, Integration Server interrupts the retry process. Depending on whether the client side queue is enabled for the JMS connection alias, either writes the JMS message to the client side queue or throws the original exception that caused the pub.jms:send service to fail. For more information, see the description for stage 5, which follows.
3
Integration Server re-executes the pub.jms:send service.
4
If the pub.jms:send service fails again because of a transient error Integration Server repeats steps 2 and 3 until one of the following occurs:
*The pub.jms:send service executes successfully.
*Retry failure occurs because the maximum number of retry attempts have been made.
5
If retry failure occurs, Integration Server will do one of the following depending on whether or not the JMS connection alias uses a client side queue:
*If the client side queue is in use, Integration Server writes the message created by the pub.jms:send service to the client side queue.
*If the client side queue is not in use, Integration Server throws the original exception thrown by the JMS provider.
Note:  
A client side queue is in use if the JMS connection alias has a Maximum CSQ Size value greater than 0 (zero) and the useCSQ input parameter is set to true for the pub.jms:send service.
Copyright © 2016 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback