How to accomplish FIFO with Azure service bus topics

5
votes

Have been looking for a Message bus with publish/subscribe functionality. Found that AWS SQS does not support FIFO, so had to give up on it. Working with Azure Service bus, found that queues do support FIFO, but it seems like Topics do not support FIFO. And topics are what we need, with their pub-to-many-sub model :(

Is it just a setting I am missing? I tried sending 100 messages from my C# client, and the subscribers got the messages in the wrong order. Any tips would be appreciated. Thanks!

2
c#azureazureservicebus
Not familiar with Azure. But with WCF you can decorate your contract with: [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single, )] Maybe there is a similiar thing for Azure? – David P
I published messages to the topic with data being messageId from 0 to 99. At the receiving end, the subscribers showed that they had received 93 before 91 etc. – mattr
stackoverflow.com/questions/7430036/… – Mohit Verma

2 Answers

2
votes

You should be able to achieve this by setting property SupportOrdering to true 

    // Configure Topic Settings
    TopicDescription td = new TopicDescription("TestTopic");
    td.SupportOrdering = true;

    // Create a new Topic with custom settings
    string connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

    var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);
    namespaceManager.CreateTopic(td);
7
votes

You can use session to get an Azure topic to provide FIFO ordering but that's not quite the same thing as guaranteeing the order in which messages are processed.

Sessions are not enough of a guarantee here. For example, if you are using PeekLock mode then a message that times out will return to the queue and be processed out of order. You can use ReceiveAndDelete mode to counter this behavior but that means you lose the transactional nature of message handling.

One of the reasons why documentation may be a little light on this area is that it isn't a common use case. Messaging is about decoupling though asynchronous communication and ordering guarantees create temporal coupling between applications.

Ideally you should design your payloads so ordering doesn't matter. If that fails, use a timestamp that allows you to discard messages received out of order.

Discussed in more detail here: Don’t assume message ordering in Azure Service Bus