If you’re following along our journey were half way through. Welcome back and thank you, the response to this series has been great. If you just joining us we are glad to have you. Since the content of this blog can be applied to almost any application that uses external services via standards like REST, you really don’t need to have read the previous episodes in the series, but I would encourage you to go back to take a look at our progress so far.
In this, the fourth episode we will show you how to handle transient faults. What are transient faults? Think of them as errors that happen in our application, then when we try the same call a couple of seconds or milliseconds later it succeeds. Transient faults can be those “hiccups” of the network or service. They could be we’ve hit a “calls per second quota”, a solar flare or just a plain old we don’t know what happened. If you want more insights on transient faults, check out this video by Allan Smith.
Note: All applications, hosted in the cloud or not, can benefit from handling transient faults. We are going address transient faults by using the retry pattern describe here.
In the following steps I’m using the Visual Studio IDE to address RESTful transient faults.
1. Right clink on your solution file and choose Manage Nuget Package for Solution. In the search box type Topaz, then hit enter. Choose to Install the EnterpriseLibrary.TransientFaultHandling to your application.
2. Add a new Class file to your project named RESTTransientErrorDetectionStrategy.cs this class will inherit from ITransientErrorDetectionStrategy in the Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling library we just add via Nuget.
3. In the RESTTransientErrorDetectionStrategy class create a private list of HttpStatusCode as below.
private readonly List<HttpStatusCode> statusCodes =
new List<HttpStatusCode>
{
HttpStatusCode.RequestTimeout,
HttpStatusCode.InternalServerError,
HttpStatusCode.BadGateway,
HttpStatusCode.ServiceUnavailable,
HttpStatusCode.GatewayTimeout
};
Add any Http Status Codes to this list that you feel are appropriately a transient fault for your application. This list may vary depending on application and usage.
4. Now implement the IsTransient interface as below.
public bool IsTransient(Exception ex)
{
var we = ex as WebException;
if (we == null)
return false;
var response = we.Response as HttpWebResponse;
var isTransient = response != null
&& statusCodes.Contains(response.StatusCode);
return isTransient;
}
We now have our own custom transient fault class for our application. Next we need to create a retry policy to go with our class.
5. In the class that calls a RESTful API create an instance of a RetryPolicy, in our case we are using an exponential back off.
RetryPolicy retryPolicy =
new RetryPolicy<RESTTransientErrorDetectionStrategy>(
new ExponentialBackoff(3, TimeSpan.FromMilliseconds(10),
TimeSpan.FromMilliseconds(10000), TimeSpan.FromMilliseconds(200)));
6. Now wrap whatever RESTful API call you want in your new RetryPolicy. For our VSO2GO application use the Index action of the Home. The altered code should look something like below.
JsonCollection<TeamProject> projects = retryPolicy.ExecuteAction(() =>
{
ProjectRestClient VsoProject = new ProjectRestClient(
this.VSORootURL, this.VisualStudioToken.accessToken);
projects = VsoProject.GetTeamProjects().Result;
return projects;
});
FlatQueryResult flatQueryRslt = retryPolicy.ExecuteAction(() =>
{
return wit.RunFlatQuery(projectName, query).Result;
});
int[] queryIDs = flatQueryRslt.WorkItems
.Select(w => w.Id)
.Take(100)
.ToArray();
JsonCollection<WorkItem> WorkItems = retryPolicy.ExecuteAction(() =>
{
return wit.GetWorkItems(queryIDs).Result;
});
The application is now protected against transient faults of the type we defined in the RESTTransientErrorDetectionStrategy using an ExponentialBackoff policy.
In the following steps I’m using the Visual Studio IDE to address SQL transient faults. If you have not been following our existing project, you will need to be using Entity Framework 6 for this portion.
1. In your project open the class that contains the DbContext. Create a new class called ApplicationDbConfiguration inheriting from DbConfiguration. Enter the code below in the constructor.
public class ApplicationDbConfiguration : DbConfiguration
{
public ApplicationDbConfiguration()
{
SetExecutionStrategy(
"System.Data.SqlClient",
() => new SqlAzureExecutionStrategy(3, TimeSpan.FromSeconds(16)));
}
}
2. Decorate the based on the class we just created.
[DbConfigurationType(typeof(ApplicationDbConfiguration))]
public class ApplicationDbContext : DbContext
The application is now protected against SQL transient faults using an ExponentialBackoff policy. The SqlAzureExecutionStrategy inherits from DbExecutionStrategy whose default is an ExponentialBackoff policy.
Watch for the upcoming Episode 5 – Getting a clear view using Application Insights, where we enable our VSO2GO with Azure Application Insights application, then add our own custom telemetry data.
Do you have an EA with Microsoft? You could be eligible for thousands of dollars in free ALM or Azure consulting! Contact us to learn how.
