Does Azure Service Bus Session guarantee the FIFO order?
Asked Answered
H

1

0

The Azure documentation https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted and different articles https://jaliyaudagedara.blogspot.com/2021/04/azure-service-bus-handling-fifo-using.html
How do you support FIFO message ordering with Azure Service Bus partitioned queues/topics?.
https://devblogs.microsoft.com/premier-developer/ordering-messages-in-azure-service-bus/.
https://connectedcircuits.blog/2020/03/19/ensuring-ordered-delivery-of-messages-using-azure-functions/.

are telling that Sessions can be used to maintain FIFO order when there are multiple receivers listening to the same Queue.

From https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-sessions#sequencing-vs-sessions

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

However Don’t assume message ordering in Azure Service Bus article (written in 2014) and post by the same author Ben Morris https://mcmap.net/q/1679187/-how-to-accomplish-fifo-with-azure-service-bus-topics claims that Sessions are not enough of a guarantee.

This isn’t enough to guarantee the order in which events are processed. For example, when a consumer reads a message using the default PeekLock mode it takes an exclusive lock for a set period of time. If this lock times out then the message is returned to the queue. This means it could be processed in the wrong order or even more than once.

It is sound like a valid concern.

Does it applicable for modern Azure Service Bus? If yes, what are workarounds?

Hygrograph answered 13/11, 2021 at 0:33 Comment(0)
K
3

Azure Service bus queues that are having sessions enabled setting will be ensuring FIFO order processing for your messages. The current documentation has to be always referred as things keeps evolving. The current documentation clarifies in the below paragraph,


The session lock held by the session receiver is an umbrella for the message locks used by the peek-lock settlement mode. Only one receiver can have a lock on a session. A receiver may have many in-flight messages, but the messages will be received in order.


So, as long as your queue is session enabled, then automatically you can only send messages with the SessionId property filled in, then you can be sure of FIFO processing.

Kemper answered 13/11, 2021 at 9:0 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.