What is the standard way to handle faults in a wcf connection with a retry mechanism, specifically for azure service bus?

Question

I have looked through the sample code here here to understand how to handle connectivity issues with the azure relay. They use an exponential backoff mechanism in Microsoft.Practices.TransientFaultHandling to handle the recreation of a faulted connection:

retryStrategy = new ExponentialBackoff(100000, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(60),
            TimeSpan.FromSeconds(1));

...
...

var shouldRetry = retryStrategy.GetShouldRetry();
if (shouldRetry(retryCount++, statusBehavior.LastError, out waitPeriod))
{
    Thread.Sleep(waitPeriod);

    Open();
    Console.WriteLine("Relay Echo ServiceHost recreated ");
}

After more research, I noticed that according to the page on Microsoft.Practices.TransientFaultHandling:

This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

Then, according to the link for transient fault handling, it states:

Important: Recent versions of SDKs for both Azure Storage and Azure Service Bus natively support retries. It is recommended to use these instead of the Transient Fault Handling Application Block

However, I don't see any examples anywhere on how to implement similar behavior to the sample, but using the Azure Service Bus SDK retry class(es) instead. What is the standard way to implement this? Or, is the quote above saying there are already built in retry mechanisms for the wcf connection, such that I don't need to worry about recreating my WebServiceHost and its corresponding connection(s)?

Answer 1

I'm answering this after trying a few different solutions, and I think the best way to do this currently would be to just use the more recently updated Microsoft Transient Fault Handling Library instead of the old deprecated Microsoft.Practices.TransientFaultHandling. This library has similar functionality to the deprecated one currently being used in the sample here here, and the rest of the solution offered for an exponential backoff can still work almost the same with this newer (although definitely not new) library. If Microsoft believes this is not the way to go in the future, hopefully they will update their azure relay samples to show a recommended solution, or solutions. Then, I could update this answer.