How Reliable is access to Azure Service Bus?

Question

I have an Azure VM running a third party server process. This server process notifies me of important events by calling an executable that I give it, passing in some data as a command line argument.

This data needs to be queued and processed by another worker.

It's very important that these notifications aren't missed, so I'm wondering:

• Is it acceptable (given my requirement) to queue the messages directly to the Azure Service Bus?

• Or should I queue first to a local MSMQ, then have another worker which reads the messages from the MSMQ and pushes them into the Azure Service Bus?

Thanks

Answer 1

The access to Service Bus is very reliable, but you will always have to build your solution in order to cope with "transient faults". This way you can check if a certain fault happens (a temporary 404 on a queue, a connection problem at your side, etc). These faults are called transient faults and you should retry on them. For this, the Service Bus client has built in functionality and on a client, you can specify a RetryPolicy. There are different retry policies available and you can create your own (ExponentialBackoff, etc) Check : http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.servicebus.messaging.messagecliententity.retrypolicy.aspx

if you need your client application to be capable of working offline, then you might have to build in some custom store-forward capabilities (you mentioned MSMQ, you can also use Service Bus for Windows Server). The only downside is that there is no out of the box store-and-forward capabilities at the moment.

Hope this helps

Answer 2

The Azure Service Bus has a guarantee of 99.9% availability (no more than 8.76 hours unavailable each year). Source: http://www.windowsazure.com/en-us/support/legal/sla/

Transient errors are a natural part of the Azure platform, due to its need to move deployments between servers. They're problems caused by the Azure infrastructure "shifting" deployments around that can cause requests to fail. Re-trying the request is all that's required to solve the problem.

The real question on how to proceed is really whether you can afford to lose data. In any system, if you need some sort of guarantee that data will not go missing, you need to write your messaging code in such a way that confirms delivery of a message to a recipient before marking the message as "sent".

If you put an MSMQ service between your Azure queues and your application, you still have to deal with the possibility that this local queue might not be available - there is no way you can fire-and-forget if you need to know the messages are not being lost. There has to be a confirmation of receipt and a mechanism to retry delivery of messages you do not get a confirmation for.