Comments on: Retrying Operations

By: Rinat Abdullin

Rinat Abdullin — Sat, 06 Jun 2009 11:39:25 +0000

Retrying actions is a real life-saver, indeed.

I’m using a similar approach to transfer data between application boundaries (i.e.: from repository to DB, while resolving dead-locks, or between client applications and web services, while handling communication exceptions). Ability to inject the specific policy via the IoC from a single place makes it even more easy to

If you are interested, there is a production-quality open-source library that leverages this concept (with a configuration syntax for retry policies). Here’s the article introducing the retry aspect:

http://abdullin.com/journal/2008/12/1/net-exception-handling-action-policies-application-block.html

BTW, these policies are compatible with policies used in Windows Azure.

By: Arielr

Arielr — Fri, 05 Jun 2009 20:16:06 +0000

I have a small issue with this – the error thrown after the last retry is the last Exception. I would think about throwing a ExceptionWithExceptions thingie – it might allow invokers to better know what went wrong along the way.

Sorry for nitpicking.

By: Tony Rasa

Tony Rasa — Fri, 05 Jun 2009 15:26:52 +0000

@Stefano: because I needed the caller to have synchronous semantics, so i do need the calling thread to be blocked until we succeed or fail. in this case the timing can be off by hundreds of ms, it doesn’t make much of a difference – i’m just saying wait ‘for a bit.’ I could have used a Timer, and then a ManualResetEvent and a callback or something to stop until the timer fires, I guess.

@udi: not really. I think using msmq for this (and only this) would be overkill.

By: Dew Drop - June 5, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop - June 5, 2009 | Alvin Ashcraft's Morning Dew — Fri, 05 Jun 2009 12:42:56 +0000

[...] Retrying Operations (Tony Rasa) [...]

By: Udi Dahan

Udi Dahan — Fri, 05 Jun 2009 09:57:57 +0000

It sounds like you’re trying to implement MSMQ.

By: Reflective Perspective - Chris Alcock » The Morning Brew #362

Reflective Perspective - Chris Alcock » The Morning Brew #362 — Fri, 05 Jun 2009 07:21:48 +0000

[...] Retrying Operations – Tony Rasa investigates a reusable way of performing operations which you expect may fail and require retrying [...]

By: Stefano Martinz

Stefano Martinz — Fri, 05 Jun 2009 05:12:55 +0000

Hi, why not use a Timer, instead of Thread.Sleep? It’d be non-blocking and the timing would be much more reliable. cheers

By: Dylan Thomas

Dylan Thomas — Fri, 05 Jun 2009 03:48:17 +0000

I remember something similar that Davy Brion did to implement the circuit breaker pattern some time ago. Obviously a slightly different use case, but still close enough to bear looking at: http://davybrion.com/blog/2008/05/the-circuit-breaker/

By: Jan Van Ryswyck

Jan Van Ryswyck — Thu, 04 Jun 2009 19:28:20 +0000

I wrote something similar about a month ago. Glad to see that the solution I came up with matches the one developed by a thought leader. . Good stuff.

By: Robert

Robert — Thu, 04 Jun 2009 18:46:40 +0000

I’ve also done something similar – in addition to the error filter that Jon suggested I also used a retry filter to see if retrying again was appropriate. I immediately added a MaxAttempts and Timeout filter and ended up adding ones like “ProcessIsRunning” and “MachineIsNotPingable”