Azure Function | Service Bus Queue Trigger | Session Enabled

April 5, 2023

Scenario

Sequence number in a service bus message only guarantees the extractor order of messages, but not the processing order. In the diagram below to make sure M1, M2 & M3 are processed also in order, it requires sessions to be enabled on the service bus queue.

[attachment=36752:name]

In the diagram, there are three messages in the service bus queue M1, M2 & M3. And there are two competing consumers (Consumer1 & Consumer2) listening to the message broker.

Consumer1 picks up M1.
Consumer2 picks up M2. Consumer 2 finishes processing M2 and
Consumer2 picks up M3

At this point, Consumer1 has not completed processing M1 yet. Consumer2 finishes processing M3 but consumer1 is still not done with processing message 1 yet. Finally, consumer1 completes processing M1.

If we pay close attention, in this scenario messages are processed in this order: M2, M3, and in the last M1.

So, if you need M1, M2, and M3 to be extracted and processed in order, you need to use sessions.

If messages just need to be retrieved in order, you don't need to use sessions.

How does Azure function process messages in a session enables service bus queue

[attachment=36753:name]

[attachment=36754:name]

If we could investigate a session enabled service bus queue, it would look like shown in the diagram above. Service bus queue internally will have virtual queues corresponding to each session to stores messages belonging to one session.

Session enabled service bus queue triggered Azure function can process messages from session enabled message broker. You need to set Session Enabled property to true in queue trigger definition for Azure function.

Azure functions each scaled instance gets an exclusive lock on one session and then it processes message in that session in order. Each scaled instance will wait for messages in session for a configurable amount of time and once that time is elapsed, exclusive lock for that session will expire and after that, scaled instance will be ready to process messages from another session. This value is configured in host.json file. In the example shown below, each scaled instance will wait for messages in session for 1 minute.