Storage Queue vs Service Bus Queue - Polling/Cost question

3
votes

I have a slightly philosophical problem. We are using Storage Queues for processing the "tickets". The way we have implemented that is we have a background service (worker role) that is polling the storage queue and finding out if there is any ticket to be processed. The nature of the work we do is seasonal. Which means that there won't be tickets all the time to be processed. The problem we are facing with this is - since multiple worker role instances are continuously polling the storage queue, we have cost impact as it's just too many GetMessage() calls.

I came across the Service Bus queue which has event-based capability. There we have the concept of OnMesage() which gets called every time a new message becomes available on a service bus queue.

But my question is - does OnMessage() goes ahead and calls Receive() internally? Which means is it just syntax sugar and internally it is still polling going on and would there be a cost impact in Service Bus Queue case as well?

Any insights into this will be helpful.

1
azureazure-servicebus-queuesazure-storage-queuescost-management
Based on stackoverflow.com/questions/40596942/…, I am inclined to say that OnMessage calls Receive internally. Though I am not able to find any evidence to prove that. – Gaurav Mantri

1 Answers

2
votes

Azure Service Bus client is using long polling to retrieve messages from the broker. By default, it's set to 1 minute or when a message arrives. So if you have a message showing up earlier than 1 minute elapses, it will be retrieved and another poll for 1 minute will be issues. OnMessage/MessageHandler are no exception. It's a higher level abstraction on top of low level receive operation.