Posted by U.S. Wickramasighe | Posted on Wednesday, November 09, 2011
It has been a while since i blogged :)...In this article i thought of explaining how to configure WSO2 ESB to enable simple message redelivery. Way we do that is through ESB endpoints more specifically through a failover endpoint. Reason i thought of coming up with this topic was the simple fact that, there are several mechanisms to do this kind of thing and enforce different levels of reliability through WSO2 ESB. And many a times users would go for advanced options not knowing that there are simpler ways to achieve what is relevant for their setup or the environment.
Let's define the following simple configuration in the ESB with a failover endpoint .Please note we are connecting to a sample Axis2 Server as the backend service. This is shipped with WSO2 ESB by default. please refer to (http://wso2.org/project/esb/java/4.0.0/docs/samples_setup_guide.html#Starting) for more information on how to set that up.
<proxy name="StockQuoteProxy" transports="https http" startOnLoad="true" trace="disable">
Try sending the message to StockQuoteProxy. You can use our default axis2 Client (http://wso2.org/project/esb/java/4.0.0/docs/samples_setup_guide.html#Using) to do that...
ant stockquote -Daddurl=http://localhost:8280/services/StockQuoteProxy
You'll get a response back as usual..Now let's make the back-end service(ie:- http://localhost:9000/services/SimpleStockQuoteService) temporarily unavailable and try to send the message again.
This time you'll notice through the console , that ESB is trying to re-attempt the message delivery . So now if you were able to make the endpoint available again you would see the response coming back to the client (of course if the client does NOT time out).. This way we can enable a simple retry-re-delivery mechanism through failover endpoints.
Failover endpoints usually fallback to the endpoint that is not in a suspended state. However since we have NOT specified multiple endpoints to fail-over , trick is making the child endpoint active at all times. We do that by specifying errorCodes -1 == > make endpoint suspend to NO error code
However this may not be desirable for some scenarios. There may be some critical errors (ie:- connection errors which may last for some time such as i/o or network errors) that you know you would not want ESB to waste time and resources , on redelivery. In that case you can define an error code/s that endpoint would really get suspended on and actually suspend for a time window, until the endpoint could probably recover..
<!-suspend for an I/O failure->
<!-here suspend for 100 sec->
So here is the gist of what i have been trying to convey, -> If you encounter a scenario where you want to have simple redelivery on , you can opt for a failover endpoint setup though ESB. These are cases such as back end services may be unavailable for a very short period of time or you don't really want to configure transactional flows that will complicate the existing configurations,etc. For other scenarios again , ESB has many useful components that will ensure reliable delivery, transactions and QoS. JMS based transactions, Message stores and processors and dead letter channels , WS-RM through ESB are to name a few....