0

I am going through an effort to upgrade code that used the old Windows Azure Service Bus (pre 2.0).

This code based used the Enterprise Library Transient Fault Handling blocks to provide a retry policy that is leveraged when calling into the Service Bus API to send and receive queue messages.

Typically the code would look like this (minus all the try/catch/finally, etc.):

 retryPolicy.Execute(() =>  { queueClient.Send(msg); });

However, in Service Bus 2.0, retry policy is built into the messaging factory, so I can set:

_msgFactory.RetryPolicy = RetryExponential.Default;
var queueClient = _msgFactory.CreateQueueClient(path, mode);

Once that is done, I can remove the TFH retry policy's Execute() wrapper around the call to queueClient.Send(msg).

Is this really all that is needed to ensure the queue client is retrying on transient exceptions? Seems to simple. How can I prove that it is retrying?

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
Thiago Silva
  • 14,183
  • 3
  • 36
  • 46
  • 1
    that is indeed all you need to do ;) it's not easy to simulate errors that will be handled transient. maybe a very short network issue (although I'm not sure that client side connection issues will be seen as transient) – Sam Vanhoutte Mar 31 '14 at 18:19
  • @SamVanhoutte Thanks! If you post your comment as an answer I'll mark it answered. – Thiago Silva Apr 02 '14 at 16:45

1 Answers1

1

that is indeed all you need to do ;) it's not easy to simulate errors that will be handled transient. maybe a very short network issue (although I'm not sure that client side connection issues will be seen as transient)

Sam Vanhoutte
  • 3,247
  • 27
  • 48