CAP published messages order into Azure Service Bus
I have updated DotNetCore.CAP.AzureServiceBus and DotNetCore.CAP from version 7.0.0 to version 8.0.1.
I've noticed the order of messages that we publish from cap has changed. In version 7.0.0, if we raise message A first then message B and then message C, we used to see the same order being published to Azure Service Bus (and also same order being consumed as we have session enabled in our service bus).
Since the package upgrade, the order of published messages into the queue is no longer guaranteed. We see random order of messages in the queue.
I could not find what has changed since version 7.0.0 of CAP. Is there anything we need to do to guarantee the order of published messaged into the queue in latest version of CAP?
FYI, I have rolled back the CAP version to 7.0.0 with Azure.Messaging.ServiceBus package in latest version and I can see the order of messages being published to the queue is correct.
Thanks :)
I think it might be related to the improvements #1380 in version 7.2 . Since version 7.2, the task of publishing messages has been handled by the .NET thread pool. Tasks in the thread pool are not guaranteed to be executed in order, which is intended to enhance the performance of message publishing.
Thanks for the response @yang-xiaodong ,
Is there a way to facilitate the order of the messages that are being published? Can we maybe set the ProducerThreadCount into 1 to have a single thread to process the messages ?
Any thoughts or ideas will be appreciated. Thanks
@yang-xiaodong I'd also like to be able to keep the order of the events being published. We have a number of flows that just need to be in that exact order. Can we explore the possibility of allowing this package to expose the relevant settings/options to achieve this?
Hi,
In version 8.1.0 we will change default behavior to serial sending messages, and add new option EnablePublishParallelSend to support parallel sending.
Version 8.1.0-preview-225165712 is released to nuget.
Thank you
Thanks @yang-xiaodong , huge help.
@yang-xiaodong your fix resolved our issue. Thanks for the change.
Fixed in version 8.1.0