Someone tweeted @endjin this week to ask if we were still supporting our Endjin.Retry framework; they asked because they were worried it had been abandoned because it had only had 6 minor commits in 2014. I replied to confirm that we have not abandoned this project in the slightest, in fact it’s one of our most used, core bits of IP (along with Endjin.Composition), that we use in practically every project we develop whether it’s related specifically to Azure or not. We have found that it is easier to extend Endjin.Retry, through its IRetryPolicy and IRetryStrategy inside the consuming project rather than pollute the core library – this means all of these customisations happen in our private project repos, not in the public Endjin.Retry repo.
Below are a series of examples of custom retry policies we’ve implemented in various projects:
This a very simple retry policy that will retry if a HttpRequestException is encountered. A good general purpose transient HTTP error retry strategy
This retry policy was specifically designed to work with the Azure Storage SDK will retry on any exception except for a HTTP 409 Conflict status code – a scenario whereby the resource you’re trying to create already exists.
Similar to the previous policy, this retry policy will retry except for a HTTP 304 Not Modified status code.
The following retry policy was created to retry except in the event of a HTTP Protocol error or a HTTP 409 Conflict status code
This retry policy is part of our Endjin.Leasing framework, which implements Mutex operations over Azure Blob Storage and will retry unless a LeaseAcquisitionUnsuccessfulException is detected, and would enable a scenario whereby you’d have a series of competing actors who want perform an action against a specific resource, the first to obtain the Mutex wins and the other actors fail fast.
This retry policy is also part of our Endjin.Leasing framework but enables the opposite scenario than the previous policy; if multiple actors want to perform an action on a particular resource, the should retry until the obtain their Mutex:
Hopefully these examples show how easy it is to implement your own retry policies, which nicely encapsulate your success and failure conditions.
Howard spent 10 years as a technology consultant helping some of the UK's best known organisations work smarter, before founding endjin in 2010. He's a Microsoft ScaleUp Mentor, and a Microsoft Azure MVP. You can follow him on Twitter via @HowardvRooijen