0

We're not using topics for Azure Service Bus (Which I understand has additional requirements to support ordering, and my understanding was that each queue should revert to operating in a FIFO manner; however, from analysing our logs just for today, we've had 384 of 15442 messages dequeued in a different order to when they were enqueued

To illustrate with an example, we had two messages, d4350a6e68ad4c9fb1fb9ccebd766590 and 0e19fbd29ffd4c4693fff6dd57e4f683; these were enqueued at 2018-11-14 09:27:31.8870000 and 2018-11-14 09:27:35.5950000 respectively (so 0e... was 4ish seconds later than d4...) However, they were dequeued at 2018-11-14 09:30:12.0320000 and 2018-11-14 09:29:57.4850000 respectively (so d4... was 15ish seconds later than 0e...). Over this timescale, we only had a single host active doing both enqueueing and dequeueing.

Whilst the timings on this are relatively close in human terms, we've seen

As I understood the queues to be, well, queues, I'm a little surprised that I'm seeing this behaviour - do I need to do any additional magic to ensure they are dequeued in the order they were enqueued?

For reference, the code that is enqueueing looks a little like:

var brokeredMessage = new BrokeredMessage(objectToQueue, new DataContractJsonSerializer(typeof(T)));            

var queueClient = QueueClient.CreateFromConnectionString(connectionString);
queueClient.RetryPolicy = new RetryExponential(TimeSpan.FromSeconds(2), TimeSpan.FromSeconds(5), 5);
queueClient.Send(brokeredMessage);

And we're dequeueing with an Azure Webjob using a service bus trigger

Rowland Shaw
  • 37,700
  • 14
  • 97
  • 166

1 Answers1

1

It is expected behavior. To ensure that the messages are processed in order, you should use Sessions in Service Bus Queues.

This will allow you to process the messages in the sequence in which the messages are en-queued.

Arunprabhu
  • 1,454
  • 9
  • 15