In debugging some Windows Azure Storage code, I ran across a seemingly spurious, unpredictable exception in Azure Blob code where I was creating Blob containers and uploading Blobs to the cloud. The error would appear sometimes… at first there was no discernable pattern… and the code would always work if I ran my code again immediately after a failure. Mysterious…

A Surprising Exception is Raised

When there was an exception raised, this was the error message with some details:

The title bar reads “StorageClientException was unhandled” which is accurate, since that code was not currently in a try/catch block. No problem or surprise there, at least with that part. But the exception text itself was surprising: “The specified container does not exist.”

Uhhhh, yes it does! After calling GetContainerReference, container.CreateIfNotExist() was called to ensure the container was there. No errors were thrown. What could be the problem?

A Clue

Okay, here’s a clue: while running, testing, and debugging my code, occasionally I would want a completely fresh run, so I would delete all my existing data stored in the cloud (that this code cared about at least) by deleting the whole Blob container (called “AzureTop40”). This was rather convenient using the handy myAzureStorage utility:

This seemed like an easy thing to do, since my code re-created the container and any objects needed. Starting from scratch was a convenience for debugging and testing. Or so I thought…

Azure Storage is Strongly Consistent, not Eventually Consistent

Some storage systems are “eventually consistent” – a technique used in distributed scalable systems in which a trade-off is made: we open a small window of inconsistency with our data, in exchange for scalability improvements. One example system is Amazon’s S3 storage offering.

But, per page 130 of Programming Windows Azure, “Windows Azure Storage is not eventually consistent; it is instantly/strongly consistent. This means when you do an update or a delete, the changes are instantly visible to all future API calls. The team decided to do this since they felt that eventual consistency would make writing code against the storage services quite tricky, and more important, the could achieve very good performance without needing this.”

So there should be no problem, right? Well, not exactly.

Is Azure Storage actually Eventually Strongly Consistent?

Okay, “Eventually Strongly Consistent” isn’t a real term, but it does seem to fit this scenario.

I’ve heard more than once (can’t find authoritative sources right now!??) that you need to give the storage system time to clean up after you delete something – such as a Blob container – which is immediately not available (strongly consistent) but is cleaned up as a background job, with a garbage collection-like feel to it. There seems to be a small problem: until the background or async cleanup of the “deleted” data is complete, the name is not really available for reuse. This appears to be what was causing my problem.

Another dimension of the problem was that there was no error from the code that purportedly ensured the container was there waiting for me. At least this part seems to be a bug: it seems a little eventually consistent is leaking into Azure Storage’s tidy instantly/strongly consistent model.

I don’t know what the Azure Storage team will do to address this, if anything, but at least understanding it helps suggest solutions. One work-around would be to just wait it out – eventually the name will be available again. Another is to use different names instead of reusing names from objects recently deleted.

I see other folks have encountered the same issue, also without a complete solution.