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. |