CDN — Do you get corrupt data while an update on the content is happening?

A lot of interesting things have been going on lately on the Windows Azure MVP list and I’ll be try to pick the best and the ones I can share and make some posts.

During an Azure bootcamp another fellow Windows Azure MVP, had a very interesting question “What happens if someone is updating the BLOB and a request come in for that BLOB to serve it?”

The answer came from Steve Marx pretty quickly and I’m just quoting his email:

“The bottom line is that a client should never receive corrupt data due to changing content.  This is true both from blob storage directly and from the CDN.

The way this works is:
·         Changes to block blobs (put blob, put block list) are atomic, in that there’s never a blob that has only partial new content.
·         Reading a blob all at once is atomic, in that we don’t respond with data that’s a mix of new and old content.
·         When reading a blob with range requests, each request is atomic, but you could always end up with corrupt data if you request different ranges at different times and stitch them together.  Using ETags (or If-Unmodified-Since) should protect you from this.  (Requests after the content changed would fail with “condition not met,” and you’d know to start over.)

Only the last point is particularly relevant for the CDN, and it reads from blob storage and sends to clients in ways that obey the same HTTP semantics (so ETags and If-Unmodified-Since work).

For a client to end up with corrupt data, it would have to be behaving badly… i.e., requesting data in chunks but not using HTTP headers to guarantee it’s still reading the same blob.  I think this would be a rare situation.  (Browsers, media players, etc. should all do this properly.)

Of course, updates to a blob don’t mean the content is immediately changed in the CDN, so it’s certainly possible to get old data due to caching.  It should just never be corrupt data due to mixing old and new content.”

So, as you see from Steve’s reply, there is no chance to get corrupt data, unlike other vendors, only old data.

PK.

Bug in SQL Azure documentation on how to calculate DB size.

A fellow Windows Azure MVP, Rainer Stroper, had a very interesting case recently were he got a “reached quota” message for his SQL Azure database, although the query was indicating he was using about ~750MB on a 1GB size Web Edition database.

The problem was narrowed done to a bug in the documentation ( http://msdn.microsoft.com/en-us/library/ff394114.aspx) and the correct one to use is this, as per Microsoft’s Support suggestion:

SELECT SUM(reserved_page_count)*8.0/1024 + SUM(lob_reserved_page_count)*8.0/1024 FROM sys.dm_db_partition_stats

in order to take accruate metrics.

Be sure you use that, so you won’t have any unpleasant suprises.

PK.

Joining Devoteam Belgium

This week, I’ve joined Devoteam Belgium as a .NET Consultant and Microsoft Trainer, focused on Windows Azure and Sharepoint and of course Trainings. It’s been a great starting week, meet a lot of interesting people and found out that there are other MVPs working around me:

Which is really really cool.

I’m looking forward to missions and trainings and I’m really happy to be here. Great people, great environment and a lot of positive vibe in the air. What can you ask more?

PK.

Go to top