Is Azure Service Bus message pump really event-driven?

Question

So we've been looking into the Azure Service Bus recently and we're a bit confused as to whether we should use an infinite loop to poll the queue/subscription or whether we should use the OnMessage callback/message pump functionality. What is going to execute fewer operations and thus cost less?

Ideally we want an event-driven system so we aren't wasting operations and it's just generally a much nicer approach.

My question is, is using OnMessage which is defined as "Processes a message in an event-driven message pump" really event-driven?

If you take a look at this page (QueueClient.OnMessage): https://msdn.microsoft.com/library/azure/microsoft.servicebus.messaging.queueclient.onmessage.aspx you'll notice the remark at the bottom which states that it is basically a wrapper around an infinite loop which is calling the Receive() method. That doesn't sound very event-driven to me.

Now if you look at this page (SubscriptionClient.OnMessage): https://msdn.microsoft.com/en-us/library/azure/dn130336.aspx, that remark is not present. So is it the same for topics/subscriptions and queues or is it actually event-driven for subscriptions but not for queues?

Why are they even saying it's event-driven when it's clearly not? The fact that the remark on the QueueClient.OnMessage page has the words "infinite loop" and "every receive operation is a billable event" is somewhat scary.

Also, I'm not really concerned about how much/little it will cost either way, I'm more interested in making it as efficient as possible.

Organometallic

Answer 1

I've not used OnMessage, but the question interested me so I did some digging.

My understanding is that the OnMessage approach just encapsulates away some of the usual concerns to do with processing messages from a queue to give you a cleaner/easier way to do it with a lot less to be concerned about. So instead of writing all the scaffolding around polling, you can focus more on a "push-like/event driven" implementation (message pump model).

And so you are correct in that it is basically still just a loop calling Receive() - so with the default timeouts, the number of polls would be the same and therefore same cost.

I came across these references:

http://fabriccontroller.net/introducing-the-event-driven-message-programming-model-for-the-windows-azure-service-bus/

http://www.flyersoft.net/?p=971 - check the comments too, as this covers the same question as yours.

So is it the same for topics/subscriptions and queues or is it actually event-driven for subscriptions but not for queues?

I am not 100%, but my assumption based on my research is that it is the same and it's just a case that the documentation is not clear.

Hacking

Thanks Ada. Seems like it is as I thought and not event-driven at all. I find it pretty strange that they still call it event-driven though. – Organometallic

At some layer of abstraction it is event-driven, and I guess that makes it great for checking bullets on marketing materials. – Delmydeloach