...
A "Suspended" endpoint cannot send or receive messages. When an endpoint is put into this state, the ESB waits until after an initial duration has elapsed (default is 30 seconds) before attempting to send messages to this endpoint again. If the message succeeds, the endpoint is marked as "Active." If the next message fails, the endpoint is marked as "Suspended" or "Timeout" depending on the error, and the ESB waits before retrying messages using the following formula:
Max Min(initial current suspension duration * (progression factor ^ retry count), maximum duration)The retry count is the number of times the ESB has attempted to send messages to this endpoint after it entered the current Suspended state. progressionFactor, maximumDuration)
You configure the initial suspension duration, progression factor, and maximum duration as part of the suspendOnFailure settings. As the On each retry count increases, the next Suspension time period will also increasesuspension duration increases, up to the maximum duration.
...
Name | Values | Default | Description |
|---|---|---|---|
errorCodes | Comma separated list of error codes | All the errors except the errors specified in | Errors that send the endpoint into the "Suspended" state. |
initialDuration | milliseconds | 100030000 | After an endpoint gets "Suspended," it will wait for this amount of time before trying to send the messages coming to it. All the messages coming during this time period will result in fault sequence activation. |
progressionFactor | Integer | 1 | The endpoint will try to send the messages after the
|
maximumDuration | milliseconds | Long.MAX_VALUE | Upper bound of retry duration. |
...
| Code Block |
|---|
<endpoint name="Sample_First" statistics="enable" >
<address uri="http://localhost/myendpoint" statistics="enable" trace="disable">
<timeout>
<duration>60000</duration>
</timeout>
<markForSuspension>
<errorCodes>101504, 101505</errorCodes>
<retriesBeforeSuspension>3</retriesBeforeSuspension>
<retryDelay>1</retryDelay>
</markForSuspension>
<suspendOnFailure>
<errorCodes>101500, 101501, 101506, 101507, 101508</errorCodes>
<initialDuration>1000</initialDuration>
<progressionFactor>2</progressionFactor>
<maximumDuration>64000<<maximumDuration>60000</maximumDuration>
</suspendOnFailure>
</address>
</endpoint>
|
In this example, the errors 101504 and 101505 move the endpoint into the "Timeout" state. At that point, three requests can fail for one of these errors before the endpoint is moved into the "Suspended" state. Additionally, errors 101500, 101501, 101506, 101507, and 101508 will put the endpoint directly into the "Suspended" state. The error 101503 is not listed, so if a 101503 error occurs, the endpoint will remain in the "Active" state.
When the endpoint is first suspended, the retry happens after one second. Because the progression factor is 2, the next suspension duration before retry is two seconds, then four seconds, then eight, and so on until it gets to sixty seconds, which is the maximum duration we have configured. At this point, all subsequent suspension periods will be sixty seconds until the endpoint succeeds and is back in the Active state, at which point the initial duration will be used on subsequent suspensions.
For more information about error codes, see Error Codes.
...