Retry Mechanisms
The retry facility is provided by Integration Server. The facility depends on what adapter construct detected the failure. A retry is configured with a retry count and a backoff time. Retry count sets the number of times the action will be tried before being considered a fatal error. The backoff time is the time waited between retries. Note that throwing a non-retryable exception on any retry iteration will be treated as a fatal exception and the retries will stop.
The following is a list of adapter objects and how retry behavior applies to each:
Connection Pools. Retry is possible at pool startup. If the backend system is down and the user tries to enable the pool from
webMethods Integration Server Administrator, the pool startup will retry until the number of retries is exhausted or the retryable exception goes away. If retries are exhausted, the pool will become disabled. Retries also occur when the pool is created during server startup.
Listeners. Retry is possible during listener startup or during execution. If the number of retries is exhausted, the listener will become disabled. By default, if during execution the Listener Notification produces an AdapterConnectionException, it will cause the corresponding listener to go into retry mode.
Adapter Services.
Integration Server provides retry mechanism on services invoked from triggers or flow invokes. An AdapterConnectionException caught from the adapter services execute() method, will be re-thrown as an ISRuntimeException. This exception is recognized by
Integration Server as a transient error and the retry cycle will occur.
Polling Notifications. The polling notification retry works differently then the other components. If a transient error is detected during the schedule execution the proper connection cleansing occurs. The next scheduled interval acts as the retry back off time. However, there is no maximum number of attempts. The notification will remain enabled and will fire on its next scheduled interval.