The latest Visual Studio Tools for Windows Azure (v 1.1, Feb 2010) was just released and can be downloaded here. It does not support VS2010 Beta 2, so you’ll need to either use VS2008, or wait until VS2010 RC in a few weeks. I’m really excited about this release for 1 immediate to-do in my code, and 1 would-be-fun to-do in my code. First, Windows Azure Drive beta is available in this release (called XDrive at PDC). Windows Azure Drive lets you mount an NTFS virtual hard disk (VHD) between one or more roles (onle 1 can mount the drive as for writing). The drive itself is stored in Azure Blob Storage, but behind the scenes there are some nice features (like caching) to make it a great option for Azure storage, particularly if you’re migrating an application that made extensive use direct disk I/O. Now, since the November release, Queue storage included a dequeue count property that allows you to have visibility into how many times a message has been dequeued. But, the StorageClient included with the VS tools didn’t have this property, so until now you’d have to do your own implementation to get the value. Seeing the dequeue count is pivotal in dealing with poison messages. A poison message, in queue parlance, is a message that contains malformed data that ultimately causes the queue processor to throw an exception. The result is that message isn’t processed, stays in the queue, only to be processed again and with the same result. Depending on the visibility timeout of the message (which is 30 seconds by default) this can be a disaster. Looking at the dequeue count can be key to discovering a poison message. For example, suppose you have the following exception handler: catch (Exception e)
{
if (msg != null && msg.DequeueCount > 2)
{
queue.DeleteMessage(msg);
}
If an exception was raised in attempting to process the message that wasn’t otherwise handled, we’ll get here. This is my outermost exception handler. In a workerrole, you _always_ want to make sure you have the opportunity to catch any exception, because otherwise the role will exit and recycle.
In this case, I can check the dequeue count and simply delete the message if it’s already been dequeued 3 or more times (an arbitrary number on my end, chosen because of the relatively high timeout which means the message will live for an hour before being discarded). If we hit that number, I’m going to discard the message. Optionally, I could log it to an invalid queue table, or put it in another queue, etc. The important thing is that we recognize a poison message and deal with it. With this particular queue, missing a message isn’t that critical so I can just delete the message and move on.