“retryConfig” element in WSO2 ESB facilitates developer to retry the endpoint on failure of known error codes. “retryConfig” has two different extreme flavours known as “disabledErrorCodes” and “enabledErrorCodes” to enhance user to manage known error codes on endpoint failures.
Lets take an Example based on WSO2 ESB sample 52 [1]
Above image is illustrating a simple use case of demonstrate simple load balancing among a set of endpoints use.
Given Synapse Configuration below meet above mentioned objective.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<definitions xmlns="http://ws.apache.org/ns/synapse"> | |
<sequence name="main" onError="errorHandler"> | |
<in> | |
<send> | |
<endpoint> | |
<loadbalance> | |
<endpoint> | |
<address uri="http://localhost:9001/services/LBService1"> | |
<enableAddressing/> | |
<suspendDurationOnFailure>60</suspendDurationOnFailure> | |
</address> | |
</endpoint> | |
<endpoint> | |
<address uri="http://localhost:9002/services/LBService1"> | |
<enableAddressing/> | |
<suspendDurationOnFailure>60</suspendDurationOnFailure> | |
</address> | |
</endpoint> | |
<endpoint> | |
<address uri="http://localhost:9003/services/LBService1"> | |
<enableAddressing/> | |
<suspendDurationOnFailure>60</suspendDurationOnFailure> | |
</address> | |
</endpoint> | |
</loadbalance> | |
</endpoint> | |
</send> | |
<drop/> | |
</in> | |
<out> | |
<!-- Send the messages where they have been sent (i.e. implicit To EPR) --> | |
<send/> | |
</out> | |
</sequence> | |
<sequence name="errorHandler"> | |
<makefault response="true"> | |
<code value="tns:Receiver" xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/> | |
<reason value="COULDN'T SEND THE MESSAGE TO THE SERVER."/> | |
</makefault> | |
<send/> | |
</sequence> | |
</definitions> |
Nevertheless, system admin or developer might already know about the Error Codes [2] that occurs during the endpoint failure, In order to avoid above circumstance it is possible to use “retryConfig”.
In known Error occurring situation, “disabledErrorCodes” disables the retry only for defined error codes within the configuration. Whereas, “enabledErrorCodes” will enable the retry only for defined error codes. Furthermore, it is not possible to have both keywords at the same time for given endpoint.By default, WSO2 ESB accepts only the “disabledErrorCodes” keyword in above mentioned situation.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<?xml version="1.0" encoding="UTF-8"?> | |
<definitions xmlns="http://ws.apache.org/ns/synapse"> | |
<sequence name="errorHandler"> | |
<log level="custom"> | |
<property name="MESSAGE" value="Executing default "fault" sequence"/> | |
<property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/> | |
<property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/> | |
</log> | |
<makefault response="true"> | |
<code xmlns:tns="http://www.w3.org/2003/05/soap-envelope" value="tns:Receiver"/> | |
<reason value="COULDN'T SEND THE MESSAGE TO THE SERVER."/> | |
</makefault> | |
<send/> | |
</sequence> | |
<sequence name="fault"> | |
<log level="full"> | |
<property name="MESSAGE" value="Executing default "fault" sequence"/> | |
<property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/> | |
<property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/> | |
</log> | |
<drop/> | |
</sequence> | |
<sequence name="main" onError="errorHandler"> | |
<in> | |
<send> | |
<endpoint> | |
<loadbalance algorithm="org.apache.synapse.endpoints.algorithms.RoundRobin"> | |
<endpoint> | |
<address uri="http://localhost:9001/services/LBService1"> | |
<retryConfig> | |
<disabledErrorCodes>101503</disabledErrorCodes> | |
</retryConfig> | |
</address> | |
</endpoint> | |
<endpoint> | |
<address uri="http://localhost:9002/services/LBService1"> | |
<retryConfig> | |
<enabledErrorCodes>101503</enabledErrorCodes> | |
</retryConfig> | |
</address> | |
</endpoint> | |
<endpoint> | |
<address uri="http://localhost:9003/services/LBService1"> | |
<enableAddressing/> | |
<suspendOnFailure> | |
<initialDuration>60000</initialDuration> | |
<progressionFactor>1.0</progressionFactor> | |
</suspendOnFailure> | |
</address> | |
</endpoint> | |
</loadbalance> | |
</endpoint> | |
</send> | |
<drop/> | |
</in> | |
<out> | |
<send/> | |
</out> | |
</sequence> | |
</definitions> |
Above Synapse configuration demonstrate the basic usage of “retryConfig”.
Follow the WSO2 ESB sample 52 [1] and configure the axis2servers, As per given Synapse configuration, load balancer won't retry on “server 1”s connection failure and print “COULDN'T SEND THE MESSAGE TO THE SERVER” on client side. Whereas, if “server 2”s connection failure only it will retry the other end points.
[1] http://docs.wso2.org/wiki/display/ESB470/Sample+52%3A+Sessionless+Load+Balancing+Between+3+Endpoints