3

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.

Girish Acharya
  • 235
  • 6
  • 20
  • 1
    Based on https://stackoverflow.com/questions/40596942/azure-service-bus-receive-messages-with-onmessage-method, I am inclined to say that OnMessage calls Receive internally. Though I am not able to find any evidence to prove that. – Gaurav Mantri Nov 01 '18 at 06:28

1 Answers1

2

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.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Thanks Sean. That helps. Does that mean I will be billed for 1 trasaction per each OnMessage() invocation then? – Girish Acharya Nov 02 '18 at 16:52
  • Indeed. You could, instead, look into EventGrid notifications to replace message pump. – Sean Feldman Nov 03 '18 at 00:34
  • It depends what transport you use. If you use the HTTP API, then yes, it will use long polling. But if you use AMQP, it uses a persistent connection, with events *pushed* to the client. – Cocowalla Oct 07 '20 at 21:30
  • 1
    Azure Service Bus over AMQP does *not* push messages to the clients. Clients use long polling. Pretty sure that's the case for AMQP over TCP and WebSockets both. RabbitMQ pushes messages to the consumers, not ASB. – Sean Feldman Oct 07 '20 at 23:43