Guaranteed message deliveries #3: the redelivery policy

In this third and last blog, I tell you about guaranteed message deliveries and how to monitor the redelivery policy that we have configured in the previous 2 blogs. You can find part 1 here and part 2 here.

When the delivery of a message fails the ESB will go the faultSequence. There you want to log the error message. There is also no need to send any kind of response in de faultSequence because you cannot send a response back to the queue. So you end up with a faultSequence similar to this one:

<faultSequence> <property name="SET_ROLLBACK_ONLY" scope="axis2" value="true" /> <log level="full" category="ERROR"> <property name="message" value="Message could not be delivered" /> <property name="error_code" expression="$ctx:ERROR_CODE" /> <property name="error_message" expression="$ctx:ERROR_MESSAGE" /> <property name="error_detail" expression="$ctx:ERROR_DETAIL" /> </log> </faultSequence> 

However there is a catch with this fault sequence: every time a delivery attempt fails it will log a error.
But when the message is successfully delivered after, for example, 2 attempts you will only see 2 log statements where the ESB logs that the message could not be delivered.
So it is very hard to keep track whether the message is successfully delivered or not.
This can be resolved using the following property:

<property name="deliveryCount" expression="$trp:JMSXDeliveryCount"/> 

Explanation

This property will be incremented every time that the ESB will retry to deliver the message.
I have created an example of a faultSequence that uses the JMSXDeliveryCount property:

<faultSequence> <property name="SET_ROLLBACK_ONLY" scope="axis2" value="true" /> <!-- The value needs to be the value set in the redeliveryPolicy.maximumRedeliveries parameter in the axis2.xml configuration + 1 for the initial delivery attempt. --> <property name="MaximumDeliveries" value="5" /> <property name="DeliveryLimit" expression="$trp:JMSXDeliveryCount = $ctx:MaximumDeliveries" /> <filter source="$ctx:DeliveryLimit" regex="true"> <then> <log level="full" category="ERROR"> <property name="Message" expression="concat('Delivery attempt ', $trp:JMSXDeliveryCount,' of ', $ctx:MaximumDeliveries)" /> <property name="error_code" expression="$ctx:ERROR_CODE" /> <property name="error_message" expression="$ctx:ERROR_MESSAGE" /> <property name="error_detail" expression="$ctx:ERROR_DETAIL" /> </log> </then> <else> <log level="full" category="WARN"> <property name="Message" expression="concat('Delivery attempt ', $trp:JMSXDeliveryCount,' of ', $ctx:MaximumDeliveries)" /> <property name="Delivery attempt message" value="Preparing redelivery attempt" /> <property name="error_message" expression="$ctx:ERROR_MESSAGE" /> </log> </else> </filter> </faultSequence> 

Explanation

In this configuration the ESB are 2 types of logs. It will log a warning when a delivery attempt has failed and it will do a new delivery attempt. When the redelivery limit is reached the WSO2ESB will log a error.
For this configuration to work it is important that the “MaximumDeliveries” is set to same value as is set in redeliveryPolicy.maximumRedeliveries parameter plus one for the initial attempt.

Conclusion

So now we have a setup where we save messages we cannot deliver onto a queue. We can either retry for ever or, to save computing resources and signal an abnormality, a limited number of retries with a progression factor.
Additionally you could also send messages about the failed delivery to a database, email address or even to a cellphone using a text message (SMS).
It is now up to you if you want to integrate this into your ESB to choose and set the parameters according to your use case.

If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.