Category: Components

Released: ReliabilityPatterns – a circuit breaker implementation for .NET

How to get it

Library: Install-Package ReliabilityPatterns (if you’re not using NuGet already, start today)

Source code: hg.tath.am/reliability-patterns

What it solves

In our homes, we use circuit breakers to quickly isolate an electrical circuit when there’s a known fault.

Michael T. Nygard introduces this concept as a programming pattern in his book Release It!: Design and Deploy Production-Ready Software.

The essence of the pattern is that when one of your dependencies stops responding, you need to stop calling it for a little while. A file system that has exhausted its operation queue is not going to recover while you keep hammering it with new requests. A remote web service is not going to come back any faster if you keep opening new TCP connections and mindlessly waiting for the 30 second timeout. Worse yet, if your application normally expects that web service to respond in 100ms, suddenly starting to block for 30s is likely to deteriorate the performance of your own application and trigger a cascading failure.

Electrical circuit breakers ‘trip’ when a high current condition occurs. They then need to be manually ‘reset’ to close the circuit again.

Our programmatic circuit breaker will trip after an operation has more consecutive failures than a predetermined threshold. While the circuit breaker is open, operations will fail immediately without even attempting to be executed. After a reset timeout has elapsed, the circuit breaker will enter a half-open state. In this state, only the next call will be allowed to execute. If it fails, the circuit breaker will go straight back to the open state and the reset timer will be restarted. Once the service has recovered, calls will start flowing normally again.

Writing all this extra management code would be painful. This library manages it for you instead.

How to use it

Taking advantage of the library is as simple as wrapping your outgoing service call with circuitBreaker.Execute:

// Note: you'll need to keep this instance around
var breaker = new CircuitBreaker();

var client = new SmtpClient();
var message = new MailMessage();
breaker.Execute(() => client.SendEmail(message));

The only caveat is that you need to manage the lifetime of the circuit breaker(s). You should create one instance for each distinct dependency, then keep this instance around for the life of your application. Do not create different instances for different operations that occur on the same system.

(Managing multiple circuit breakers via a container can be a bit tricky. I’ve published a separate example for how to do it with Autofac.)

It’s generally safe to add this pattern to existing code because it will only throw an exception in a scenario where your existing code would anyway.

You can also take advantage of built-in retry logic:

breaker.ExecuteWithRetries(() => client.SendEmail(message), 10, TimeSpan.FromSeconds(20));

Why is the package named ReliabilityPatterns instead of CircuitBreaker?

Because I hope to add more useful patterns in the future.

This blog post in picture form

Sequence diagram

Released: SnowMaker – a unique id generator for Azure (or any other cloud hosting environment)

What it solves

Imagine you’re building an e-commerce site on Azure.

You need to generate order numbers, and they absolutely must be unique.

A few options come to mind initially:

  • Let SQL Azure generate the numbers for you. The downside to this approach is that you’re now serializing all of your writes down to a single thread, and throwing away all of the possible benefits from something like a queuing architecture. (Sidenote: on my current project we’re using a NoSQL graph DB with eventual consistency between nodes, so this wouldn’t work for us anyway.)
  • Use a GUID. These are far from human friendly. Seriously, can you imagine seeing an order form with a GUID on the top?
  • Prefix numbers with some form of machine specific identifier. This now requires some way to uniquely identify each node, which isn’t very cloud-like.

As you can see, this gets complex quickly.

SnowMaker is here to help.

What it does

SnowMaker generates unique ids for you in a highly distributed and highly performant way.

  • Ids are guaranteed to be unique, even if your web/worker role crashes.
  • Ids are longs (and thus human readable).
  • It requires absolutely no node-specific configuration.
  • Most id generation doesn’t even require any off-box communication.

How to get it

Library: Install-Package SnowMaker

(if you’re not using NuGet already, start today)

Source code: hg.tath.am/snowmaker or github.com/tathamoddie/snowmaker

How to use it

var generator = new UniqueIdGenerator(cloudStorageAccount);
var orderNumber = generator.NextId("orderNumbers");

The only caveat not shown here is that you need to take responsibility for the lifecycle of the generator. You should only have one instance of the generator per app domain. This can easily be done via an IoC container or a basic singleton. (Multiple instances still won’t generate duplicates, you’ll just see wasted ids and reduced performance.) Don’t create a new instance every time you want an id.

Other interesting tidbits

The name is inspired by Twitter’s id generator, snowflake. (Theirs is more scalable because it is completely distributed, but in doing so it requires node-specific configuration.)

Typical id generation doesn’t even use any locks, let alone off-box communication. It will only lock and talk to blob storage when the id pool has been exhausted. You can control how often this happens by tweaking the batch size (a property on the generator). For example, if you are generating 200 order ids per server per second, set the batch size to 2000 and it’ll only lock every 10 seconds.

Node synchronisation is done via Azure blob storage. Other than that, it can run anywhere. You could quite easily use this library from AppHarbor or on premise hosting too, you’d just wear the cost of slightly higher latency when acquiring new ids batches.

The data persistence is swappable. Feel free to build your own against S3, Ninefold Storage, or any other blob storage API you can dream up.

The original architecture and code came from an excellent MSDN article by Josh Twist. We’ve brushed it off, packaged it up for NuGet and made it production ready.

Under the covers

SnowMaker allocates batches of ids to each running instance. Azure Blob Storage is used to coordinate these batches. It’s particularly good for this because it has optimistic concurrency checks supported via standard HTTP headers. At a persistence level, we just create a small text file for each id scope. (eg, the contents of /unique-ids/some-id-scope would just be “4”.)

One issue worth noting is that not all ids will always be used. Once a batch is checked out, none of the ids in it can ever be reallocated by SnowMaker. If a batch is checked out, only one id is used, then the process terminates, the remaining ids in that batch will be lost forever.

Here’s a sequence diagram for one client:

SequenceDiagram

Here’s a more complex sequence diagram that shows two clients interacting with the store, each using a different batch size:

Multiple clients

Released: FormsAuthenticationExtensions

What it does

Think about a common user table. You probably have a GUID for each user, but you want to show their full name and maybe their email address in the header of each page. This commonly ends up being an extra DB hit (albeit hopefully cached).

There is a better way though! A little known gem of the forms authentication infrastructure in .NET is that it lets you embed your own arbitrary data in the ticket. Unfortunately, setting this is quite hard – upwards of 15 lines of rather undiscoverable code.

Sounds like a perfect opportunity for another NuGet package.

How to get it

Library: Install-Package FormsAuthenticationExtensions

(if you’re not using NuGet already, start today)

Source code: formsauthext.codeplex.com

How to use it

Using this library, all you need to do is add:

 using FormsAuthenticationExtensions;

then change:

 FormsAuthentication.SetAuthCookie(user.UserId, true);

to:

 var ticketData = new NameValueCollection {
    { "name", user.FullName },
    { "emailAddress", user.EmailAddress }
 };
new FormsAuthentication().SetAuthCookie(user.UserId, true, ticketData);

Those values will now be encoded and persisted into the authentication ticket itself. No need to store it in any form of session state, custom cookies or extra DB calls.

To read the data out at a later time:

 var ticketData = ((FormsIdentity) User.Identity).Ticket.GetStructuredUserData();
var name = ticketData["name"];
var emailAddress = ticketData["emailAddress"];

If you want something even simpler, you can also just pass a string in:

 new FormsAuthentication().SetAuthCookie(user.UserId, true, "arbitrary string here");

and read it back via:

 var userData = ((FormsIdentity) User.Identity).Ticket.UserData;

Things to Consider

Any information you store this way will live for as long as the ticket.

That can be quite a while if users are active on your application for long periods of time, or if you give out long-term persistent sessions.

Whenever one of the values stored in the ticket needs to change, all you need to do is call SetAuthCookie again with the new data and the cookie will be updated accordingly. In our user name / email address example, this is actually quite advantageous. If the user was to update their display name or email address, we’d just update the ticket with new values. This updated ticket would then be supplied for future requests. In web farm environments this is about as perfect as it gets – we don’t need to go back to the DB to load this information for each request, yet we don’t need to worry about invalidating the cache across machines. (Any form of shared, invalidatable cache in a web farm is generally bad.)

Size always matters.

The information you store this way is embedded in the forms ticket, which is then encrypted and sent back to the users browser. On every single request after this, that entire cookie gets sent back up the wire and decrypted. Storing any significant amount of data here is obviously going to be an issue. Keep it to absolutely no more than a few simple values.

Twavatar – coming to a NuGet server near you

Yet another little micro-library designed to do one thing, and do it well:

twavatar.codeplex.com

Install-Package twavatar

I’ve recently been working on a personal project that lets me bookmark physical places.

To avoid having to build any of the authentication infrastructure, I decided to build on top of Twitter’s identity ecosystem. Any user on my system has a one-to-one mapping back to a Twitter account. Twitter get to deal with all the infrastructure around sign ups, forgotten passwords and so forth. I get to focus on features.

The other benefit I get is being able to easily grab an avatar image and display it on the ‘mark’ page like this:

image

(Sidenote: You might also notice why I recently built relativetime and crockford-base32.)

Well, it turns out that grabbing somebody’s Twitter avatar isn’t actually as easy as one might hope. The images are stored on Amazon S3 under a URL structure that requires you to know the user’s Twitter Id (the numeric one) and the original file name of the image they uploaded. To throw another spanner in the works, if the user uploads a new profile image, the URL changes and the old one stops working.

For most Twitter clients this isn’t an issue because the image URL is returned as part of the JSON blob for each status. In our case, it’s a bit annoying though.

Joe Stump set out to solve this problem by launching tweetimag.es. This service lets you use a nice URL like http://img.tweetimag.es/i/tathamoddie_n and let them worry about all the plumbing to make it work. Thanks Joe!

There’s a risk though … This is a free service, with no guarantees about its longevity. As such, I didn’t want to hardcode too many dependencies on it into my website.

This is where we introduce Twavatar. Here’s what my MVC view looks like:

 @Html.TwitterAvatar(Model.OwnerHandle)

Ain’t that pretty?

We can also ask for a specific size:

 @Html.TwitterAvatar(Model.OwnerHandle, Twavatar.Size.Bigger)

The big advantage here is that if / when tweetimag.es disappears, I can just push an updated version of Twavatar to NuGet and everybody’s site can keep working. We’ve cleanly isolated the current implementation into its own library.

It’s scenarios like this where NuGet really shines.

Update 1: Paul Jenkins pointed out a reasonably sane API endpoint offered by Twitter in the form of http://api.twitter.com/1/users/profile_image/tathamoddie?size=bigger. There are two problems with this API. First up, it issues a 302 redirect to the image resource rather than returning the data itself. This adds an extra DNS resolution and HTTP round trip to the page load. Second, the documentation for it states that it “must not be used as the image source URL presented to users of your application” (complete with the bold). To meet this requirement you’d need to call it from your application server-side, implement your own caching and so forth.

The tweetimag.es service most likely uses this API under the covers, but they do a good job of abstracting all the mess away from us. If the tweetimag.es service was ever to be discontinued, I imagine I’d update Twavatar to use this API directly.

Released: RelativeTime

Ruby has a nifty little function called time_ago_in_words. You pass it an arbitrary number of seconds and it gives you back something friendly like “about 2 weeks ago”.

Today, I implemented a similar routine for .NET.

relativetime.codeplex.com

nuget.org/List/Packages/relativetime

To use it, just include the namespace, then call ToHumanTime() on a TimeSpan object.

If you want more of an idea of what it generates, take a look at the test suite.

Released: Crockford Base32 Encoder

Now, doesn’t that just sound sexy? No, not really. I hear you.

Alas, I went and built it anyway.

crockfordbase32.codeplex.com

nuget.org/List/Packages/crockford-base32

Crockford Base32 lets you encode a number into an alphanumeric string, and back again.

Where it shines is in the character set it uses.

It’s resilient to humans:

  • No crazy characters or keyboard gymnastics
  • Totally case insensitive
  • 0, O and o all decode to the same thing
  • 1, I, i, L and l all decode to the same thing
  • Doesn’t use U, so a number like 519,571 encodes to FVCK instead
  • Optional check digit on the end

It’s great for URLs:

  • No funky characters that require special encoding
  • No plus, slash or equals symbols like base 64

It handles really big numbers. (Well, my implementation is limited to 18,446,744,073,709,551,615 but you could extend the algorithm even further just by changing the data type from ulong to something even bigger.)

Number Encoded Encoded with optional check digit
1 1 11
194 62 629
456,789 1CKE 1CKEM
398,373 C515 C515Z
3,838,385,658,376,483 3D2ZQ6TVC93 3D2ZQ6TVC935
18,446,744,073,709,551,615 FZZZZZZZZZZZZ FZZZZZZZZZZZZB

 

Don’t have too much fun now.

Managed Wrappers for Windows Live Data

Windows Live Data is the API you use for delegated access to your user’s personal data like contacts. It’s a pretty simple API, however that hasn’t stopped me writing some components for it! Today, I’m releasing them publicly.

Not only do these components make it easier to work with the API, but they also provide an abstraction layer so that as the API develops your application doesn’t necessarily have to.

(Note: This post assumes an understanding for the Windows Live Data API. If you’ve never touched it before, read this first.)

First up is the PermissionRequestHyperLink control. Placing this on your page gives you a nice designer experience for building those yucky URLs and setting all the right flags.

A basic request looks something like this:

<live:PermissionRequestHyperLink id=”PermissionRequestHyperLink1″ runat=”server” Permission=”LiveContacts_ReadOnly” PrivacyUrl=”~/WindowsLive/PrivacyPolicy.aspx” ReturnUrl=”~/WindowsLive/ResponseHandler.ashx”>Permission Request</live:permissionrequesthyperlink>

And gives you designer experience like this:

image

image

Next up is the response handler base class. Start by adding a new ‘generic handler’ to your project:

image

Change the generated class to inherit from PermissionResponseHandler instead of IHttpHandler, then implement the ProcessResponse and ProcessFailure methods like so:

public class ResponseHandler : PermissionResponseHandler
{
    protected override void ProcessResponse(HttpContext context, PermissionResponse response)
    {
        //Do something here like storing the token for future use
        //response.DomainAuthenticationToken
        //response.OwnerHandle
    }

    protected override void ProcessFailure(HttpContext context, PermissionResponseCode responseCode)
    {
        //Perform some nice handling here
        //responseCode
    }
}

How easy is that!

You can grab the code from http://svn.fueladvance2.com/FuelAdvance.Components/trunk/ (username: anonymous). You’ll find the components in the FuelAdvance.Components.Web.WindowsLive namespace.

If you’re using Subversion yourself, remember that you can configure this as an svn:external and then you’ll always be running the latest version.

Next up, I’ll probably be releasing some managed wrappers for the Windows Live Contacts API.

Update 9/8/07: Change SVN link to point at the solution instead of the project.