Introducing Palmer (a Retry logic library for .NET)

Over the last week I’ve been slowly writing a little utility library to make it easier to express retry logic within application code. As software becomes more complex and more interconnected the concept of gracefully recovering from transient conditions becomes more important. Your average cloud or enterprise application is going to have to deal with network time outs, database deadlocks and temporary glitches caused by underlying systems recovering from hardware failures.

Palmer is a library that I’ve created to help solve this problem. You can read more about it over at GitHub. If you just want to download it and have a play, you can install the package from NuGet.

Install-Package Palmer

Using the API is easy with its fluent syntax:

Retry.On<SqlException>().For(5).With(context =>
{
  // Some code that might throw a transient SQL exception.
});

This is a 0.1 release so I am looking for feedback and ideas on how to improve the library. I’ve already got a couple of ideas such as:

  • Extend the On/AndOn methods to allow passing in a typed exception to make accessing specific exception fields easier.
  • Add event hooks to support logging exceptions as they occur.
  • Create an extension library for common usage scenarios such as SQL, network issues.
  • Support capturing multiple exceptions with one termination condition.

I’ve also added some issues around improving the documentation and turning the library back into a portable library after getting my build issues sorted out.

About these ads

6 thoughts on “Introducing Palmer (a Retry logic library for .NET)

  1. Rory Primrose

    I always find these kind of apis confusing because it is not clear if the repeat number is inclusive or exclusive of the original atttempt. It would be good if the API could make this clear.

  2. roryprimrose

    My issue with these types of api is that it is not clear if the repeat number is inclusive or exclusive of the original attempt.

  3. wchan2011

    Interesting idea. Certainly will be very useful to commercial if a solid retry framework is available. For failed retries at work I constantly encounter the need to deal the followings:

    1. Minimum waiting time between retries.
    2. Every retry action may take a different set of arguments / data. E.g. 100 web service calls made, 50 needs retry after 1st run, 20 needs retry after 2nd run etc.
    3. Feeling that it would be nice if retries can be specified via AOP as attributes of service methods.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s