Azure-docs: Topic Support Ordering

Created on 27 Sep 2018  Â·  14Comments  Â·  Source: MicrosoftDocs/azure-docs

I have been investigating message ordering with Azure Service Bus topics. As I understand FIFO ordering is achieved if all messages are processed by the same broker. When a topic DOES NOT have partitioning, there is a single broker, which means ordered messaging with or without a sessionID (of course one broker can be a performance bottleneck and at risk to fail).

With partitioning enabled, messages with the same sessionID will be put in the same partition and worked by the same broker.

So what does TopicDescription SupportOrdering do to support ordering?


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Pri2 assigned-to-author product-question service-bus-messaginsvc triaged

Most helpful comment

Are there any architecture diagrams that show how the pump and brokers work? Or any documentation that explains this better?

All 14 comments

@mack0196
Thanks for the feedback! We are currently investigating and will update you shortly.

Hello @mack0196 , from the description here:

TopicDescription.SupportOrdering Property - Gets or sets the support ordering method.

Let us know if you have further questions?
Thanks!

I don't understand. Per MS docs and my exp, a topic\queue with partition enabled and messages with sessionID give you FIFO (per the messages with the same SessionID).

With partition enabled and messages with sessionID, what is the difference with SupportOrdering enabled or disabled?

@axisc - could you please look into it? Thanks.

In Azure Service Bus, topic-subscription is implemented as pump model. In standard messaging by default topic is having multiple pumps that pumps messages in parallel to subscriptions which could bring message out of incoming orders in topic. So while set this value to true, there is only one pump so the order will be same as the incoming orders to subscription. This is slightly different in premium messaging as for 1MU, there will be only 1 pump regardless whether this value is set to true or false.

The side effect of SupportOrdering with partition entity is that the message needs to specify session id or partition key when SupportOrdering is true to ensure all messages in the same partition range go to the same partition.

Is there a practical difference to the message ordering for messages with sessionId set when Topic.SupportOdering=true vs when SupportOrdering=false and Topic.Partition=True?

What is the practical side effects of 1pump with SupportOrdering?

Is the 1 pump behavior of premium the reason why partitions are not supported?

Does that mean that message ordering in the subscription is not guarenteed to matching incoming order when Topic.Partition=true and Message.SesssionID is set?

Can you link me to documentation describing that behavior when SupportOrdering=true?

This begs for us to fix our documentation, which is happening soon.

There appears to be some confusion to pumps and partitions (with possible conflation of concepts). that is not the case.

SupportOrdering = True means One pump
Partition = True implies multiple message brokers.

SupportOrdering enabled will ensure that the single pump respects incoming order of messages and messages flow in the same order to different partitions also.

SupportOrdering= False && Partition = True means that all messages will still be handled by the same message broker, but the different partitions may cause the incoming order of messages to be ignored.

Side effect of 1 pump + SupportOrdering (i.e. both are the same thing) is that the 1 pump will become a bottleneck.

Partitions are not supported in premium since there are already dedicated resources setup and sessions exist. 1 pump will ensure that incoming order is respected.

In standard, because of multiple pumps the incoming order is not guaranteed unless SupportOrdering is set to True.

SupportOrdering= False && Partition = True means that all messages will still be handled by the same message broker, but the different partitions may cause the incoming order of messages to be ignored.

I thought that each partition is worked by its own message broker, not the same message broker.

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-partitioning#how-it-works
Each partitioned queue or topic consists of multiple fragments. Each fragment is stored in a different messaging store and handled by a different message broker.

Will you please explain how one message pump is different than one partition?

@mack0196 sorry for the delay. A pump is not the same as a message broker.

The 'pump' is a worker thread that sends the message to different partitions as specified. Single pump implies that it reads the incoming messages one at a time and sends them to the appropriate partition.

multiple pumps(workers) may end read from the same ingress message source and then push them to different partitions. Some workers may go faster/slower than others and that may affect the ordering of messages in the partition (i.e. it won't match the incoming order of messages).

Due to this, support ordering = true, limits to a single pump.

Once the pump transfer the message to it's partition, then each partition uses it's own message broker to process the message.

hope that helps.

I understand that messages sent to the same partition will be put into subscriptions in the order the partition received them.

I don't understand how the ordering guarantee works when there are multiple partitions.

I'm considering a scenario where one partition will process slower than other. When the single pump receives two messages then sends them to different partitions, and the first message is sent to the slower partition.

How is it guaranteed that the messages will be put into subscriptions in the pump-receipt order when the partitions process independently?

@mack0196 - depends on SupportOrdering and Partitioning setup.

Request you to go through the rest of the thread, and reopen with a code repro if you are seeing any unexpected behavior.

please-close

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

Are there any architecture diagrams that show how the pump and brokers work? Or any documentation that explains this better?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

spottedmahn picture spottedmahn  Â·  3Comments

spottedmahn picture spottedmahn  Â·  3Comments

paulmarshall picture paulmarshall  Â·  3Comments

jharbieh picture jharbieh  Â·  3Comments

behnam89 picture behnam89  Â·  3Comments