WSO2 ESB can be used as an intermediary component to connect different systems. When connecting those systems the availability of those systems is a common issue. Therefore ESB has to handle those undesirable situations carefully and take relevant actions. To cater that requirement outbound-endpoints of the WSO2 ESB can be configured. In this article I discuss two common ways of configuring endpoints.
Two common approaches to configure endpoints are;
- Configure with just a timeout (without suspending endpoint)
- Configure with a suspend state
Configure with just a timeout
This would suitable if the endpoint failure is not very frequent.
<endpoint name="SimpleTimeoutEP"> <address uri="http://localhost:9000/StockquoteService"> <timeout> <duration>2000</duration> <responseAction>fault</responseAction> </timeout> <suspendOnFailure> <errorCodes>-1</errorCodes> <initialDuration>0</initialDuration> <progressionFactor>1.0</progressionFactor> <maximumDuration>0</maximumDuration> </suspendOnFailure> <markForSuspension> <errorCodes>-1</errorCodes> </markForSuspension> </address> </endpoint>
In this case we only focus on the timeout of the endpoint. The endpoint will stay as Active for ever. If a response does not receive within duration, the responseAction triggers.
duration – in milliseconds
responseAction – when response comes to a time-out message one of the following actions trigger.
- fault – calls the fault-sequence associated
- discard – discards the response
- none – will not take any specific action on response (default action)
The rest of the configuration avoids the endpoint going to suspend state.
If you specify responseAction as “fault”, you can define define customize way of informing the failure to the client in fault-handling sequence or store that message and retry later.
Configure with a suspend state
This approach is useful when connection failures are very often. By suspending endpoint, ESB can save resources without unnecessarily waiting for responses.
In this case endpoint goes through a state transition. The theory behind this behavior is the circuit-breaker pattern. Following are the three states:
- Active – Endpoint sends all requests to backend service
- Timeout – Endpoint starts counting failures
- Suspend – Endpoint limits sending requests to backend service
<endpoint name="Suspending_EP"> <address uri="http://localhost:9000/StockquoteServicet"> <timeout> <duration>6000</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>60000</maximumDuration> </suspendOnFailure> </address> </endpoint>
In the above configuration:
If endpoint error codes are 101504, 101505; endpoint is moved from active to timeout state.
When the endpoint is in timeout state, it tries 3 attempts with 1 millisecond delays.
If all those retry attempts fail, the endpoint will move to suspend state. If a retry succeed, then endpoint will move to active state.
If active endpoint receives error codes 101500, 101501, 101506, 101507, 101508; endpoint will directly move to suspend.
After endpoint somehow moves to suspend state, it waits initialDuration before attempting any furthermore. Thereafter it will determine the time period between requests according to following equation.
Min(current suspension duration * progressionFactor, maximumDuration)
In the equation, “current suspension duration” get updated for each reattempt.
Once endpoint succeed in getting a response to a request, endpoint will go back to active state.
If endpoint will get any other error codes (eg: 101503), it will not do any state transition, and remain in active state.
In this article I have shown two basic configurations that would be useful to configure endpoints of WSO2 ESB. You can refer WSO2 ESB documentation for implementing more complex patterns with endpoints.
Timeout and Circuit Breaker Pattern in WSO2 Way: http://ssagara.blogspot.com/2015/05/timeout-and-circuit-breaker-pattern-in.html
Endpoint Error Codes: https://docs.wso2.com/display/ESB500/Error+Handling#ErrorHandling-codes
Endpoint Error Handling: http://wso2.com/library/articles/wso2-enterprise-service-bus-endpoint-error-handling/