“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.
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.
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
No comments:
Post a Comment