Tag Archives: dotNet

Automatic Retry and Circuit Breaker made easy

Polly library logoIf you do not know Polly, you are missing out! I did not know about it until a couple of days ago and you properly never heard about it either, as this wonderful little library only has 63 downloads on NuGet at the time of writing.

Polly is an easy to use retry and circuit breaker pattern implementation for .Net – let me show you.
Start by specifying the policy – what should happen when an exception thrown:

  var policy = Policy
    .Handle<SqlException(e => e.Number == 1205) // Handling deadlock victim
    .Or<OtherException>()
    .Retry(3, (exception, retyCount, context) =>
    {
      // Log...
    });

The above policy specifies a SqlExeption with number 1205 or OtherException should be retried three times – if it still fails log and bobble the original exception up the call stack.

  var result = policy.Execute(() => FetchData(p1, p2));

It is also possible to specify the time between retries – e.g. exponential back off:

  var policy = Policy
    .Handle<MyException>()
    .WaitAndRetry(5, retryAttempt =>
      TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)
    );

Or the circuit breaker safeguarding against the same error occurs again and again if an external system is temporarily unavailable:

  var policy = Policy
    .Handle<TimeoutException>()
    .CircuitBreaker(2, TimeSpan.FromMinutes(1));

Go get it – I’m already using it 🙂

Accessing HTTP Request from ASP.NET Web API

Do you need access to the bare HTTP request in ASP.NET Web API to access custom header etc.? Then add the HttpRequestMessage:

public class CalculatorController : ApiController
{
  public int Add(HttpRequestMessage requestMessage, int x, int y)
  {
    var accessToken = requestMessage.Headers.Authorization.Parameter;
    // use the HTTP header

    return x + y;
  }
}

The HttpRequestMessage is automatically bound to the controller action, so you can still execute the action like http://localhost/calculator/add?x=3&y=2

Simple and easy.

WCF Throttling – Part 1

The default throttling settings in WCF has always been very conservative. There where configured conservatively to diminish the risk of request flooding. Without throttling settings a large number of requests will make the service unresponsive by consuming all resources trying to respond to all requests simultaneously.

Because of the very conservative settings many developers have run into what seems like WCF performance problems, but was actually incorrectly configured throttling settings.

WCF throttling is a service behavior configuration and each setting has effect dependent on the InstanceContextMode and ConcurrencyMode settings.

  • maxConcurrentCalls (int) – the maximum number of concurrent messages processing
  • maxConcurrentInstances (int) – the maximum number of concurrent InstanceContext (service type instances) objects processing
  • maxConcurrentSessions (int) – the maximum number of concurrent sessions processing

These throttling settings can be configured in code via the ServiceThrottlingBehavior in the System.ServiceModel.Description namespace or though configuration like below:

<system.serviceModel>
    <serviceBehaviors>
      <behavior name="throttlingServiceBehavior">
        <serviceThrottling maxConcurrentCalls="16"
                           maxConcurrentInstances="160"
                           maxConcurrentSessions="10"/>
      </behavior>
    </serviceBehaviors>
</system.serviceModel>

The default values in .Net 3.0/3.5 are:

  • maxConcurrentCalls = 16
  • maxConcurrentSessions = 10
  • maxConcurrentInstances = maxConcurrentCalls + maxConcurrentSessions

The default has changed in .Net 4.0 as the .Net 3.0/3.5 default values were too conservative and the increase in server resources – especially the number of cores available. The default values for .Net 4.0 are:

  • maxConcurrentCalls = 16 * Environment.ProcessorCount
  • maxConcurrentSessions = 100 * Environment.ProcessorCount
  • maxConcurrentInstances = maxConcurrentCalls + maxConcurrentSessions

The Environment.ProcessorCount property is misleading as the value is the number of cores (Hyper-Threading counts double). In my development laptop with four Hyper-Threading cores looks like this:

Miracle Open World 2010 Lucene Presentation

The conference is over and it was a great success. I meet a lot of new people and had lots of technical discussions about .Net, graph databases, freetext search, SQL Server, Oracle Service Bus, debugging with WinDbg and extensions.

The slides and demo code for my Lucene session is available here:

My session “Making freetext search with Lucene.Net work for you” abstract:

Lucene is an open source full-featured text search engine library, making searching in large amounts of text lightning fast. Lucene are in use by many large sites like Wikipedia, LinkedIn, MySpace etc.

It is easy to get started with Lucene, but there are many pitfalls… In this session you will learn about the do’s and don’t’s for indexing and searching, tools, scaling, new features in version 2.9 and some of the more advanced features.

This presentation will use the Microsoft .Net implementation of Lucene named Lucene.Net, but the content of this presentation applies for ported versions of Lucene.