Add support for message sessions

[SeanFeldman]

Is your feature request related to a problem? Please describe.
For a long time Particular has shied away from ordered messages delivery for historical reasons. The originally supported MSMQ transport did not provide guaranteed ordered delivery and the rest of the transports were molded into the assumption that ordered message processing is either not something that should be done, or accomplished using the saga feature.

More modern technologies such as Azure Service Bus are capable of handling messages in the order those were sent, providing a feature called Message Sessions.

Describe the solution you'd like
Add support for message sessions to allow endpoints that require message ordered processing at scale to do the job without resorting to more complex solutions such as sagas and state persistence.

Additional context
There are domains where message processing in the order those were sent is critical. Even the pizza pizza preparation process.

[ramonsmits]

@SeanFeldman thanks for the suggestion but AFAIK message sessions are only providing ordering for a specific sender. If multiple senders. For example, sessions are useful in the context of multiple operations. Similar as in the past NServiceBus supported message send batches.

In the context of this feature request, are you talking about a message session that contains all outgoing message for a single incoming message. In other words, how would you want to see the life-time from the perspective of the sender?

[SeanFeldman]

but AFAIK message sessions are only providing ordering for a specific sender.

That's incorrect. Different senders can contribute messages for a given session.

For example, sessions are useful in the context of multiple operations. Similar as in the past NServiceBus supported message send batches.

No, @ramonsmits. That's not the same at all. I think you're mixing up messages grouped with Message Sessions. Have another look at the ASB-specific feature.

In the context of this feature request, are you talking about a message session that contains all outgoing message for a single incoming message. In other words, how would you want to see the life-time from the perspective of the sender?

Senders are not the problem. Those can send messages and specify session ID. This, in theory, should be already possible with native message access. Processing a single message should be done in the context of a session. Wherever there's a single message for that session or multiple messages, it doesn't matter. From NSB's perspective, it still receives one message at a time. It's how it receives it needs to be mindful of whether the entity is session-enabled.

[tedvanderveen]

I think it's hard to over estimate the importance of adding support for ASB Sessions feature, as it is the only way to enable FIFO in ASB. In many scenarios correct handling of ordered events/messages is important. ASB Sessions offer a way to guarantee ordered processing and ensure that only a single queue/topic processor can process messages with the same SessionID.

[GaryFail]

Is there any update on this? Sessions on Azure Service Bus have been a life saver allowing us to scale out our receiving system, however the lack of support for this prevents us from using NServiceBus.

A simple example of the need for this would be a hospital admissions department admit a patient followed by quickly discharging them, two messages are published respectively, when only one instance of the consumer exists all is fine, but if we scale out to two or more instances in reality one could process the discharge first whilst the other is processing the admission with no knowledge of the discharge. This could result in a patient remained on the subscribing system as admitted.

The use of Azure Service Bus sessions and locking the session to the instance of the subscriber allows us to handle this but not if we move to NServiceBus, resulting in our inability to scale out.

[WilliamBZA]

No progress yet, but this feature request is on our radar, and was picked up recently for consideration but didn't quite make it to implementation then. We'll update this issue with progress when we start actively unpacking this.

[GaryFail]

Brilliant, thanks for the response William

[jdt]

Any more news on this? Does the fact that it was picked up for consideration mean we could have this feature in the foreseeable future?

[kbaley]

No new information yet. But we appreciate the comments. They help us determine what people are asking for to help with prioritization.

[lena-osterhus]

What is the status of this feature request?

We’re already using NServiceBus with Azure Service Bus transport in our Azure Function Apps and are running into issues when they are scaling out.

In short, an Azure Function App is scaling out, causing messages related to the same “session” (e.g., messages about the same Customer) to be processed in parallel across multiple instances. However, we need all messages concerning a given Customer to be processed by the same instance.

[DavidBoike]

While I can't promise that we are going to start working on this feature in the near future, I would like to get additional context on it, which can only help its hopes of getting prioritized. Right now it's too nebulous for that to be a realistic option.

I'd like to know how those participating in this thread would imagine sessions would/could be implemented in an NServiceBus context. From what I understand, a session is normally going to be associated with something temporary, as when @lena-osterhus mentioned a session being related to a single customer. So you could not configure an endpoint to only pay attention to a preconfigured session, as that would ignore all other messages not in that session, and wouldn't even be vaulable forever, as once that customer went away, no messages would apply.

I didn't review the nitty-gritty of how the Azure Service Bus transport works, but I want to say there is only one receiver that is grabbing messages and assigning them to worker threads until it hits the concurrency limit. It's not like for MaxConcurrency=8 there are 8 different receivers…the concurrency is managed by a Semaphore. So how would that have to change in a world where the transport supports sessions?

[SeanFeldman]

From what I understand, a session is normally going to be associated with something temporary, as when @lena-osterhus mentioned a session being related to a single customer.

Correct.

So you could not configure an endpoint to only pay attention to a preconfigured session, as that would ignore all other messages not in that session, and wouldn't even be vaulable forever, as once that customer went away, no messages would apply.

Corect again. If someone needs a specific session affinity, then NSB is not the right tool for them.

I didn't review the nitty-gritty of how the Azure Service Bus transport works, but I want to say there is only one receiver that is grabbing messages and assigning them to worker threads until it hits the concurrency limit. It's not like for MaxConcurrency=8 there are 8 different receivers…the concurrency is managed by a Semaphore. So how would that have to change in a world where the transport supports sessions?

Multiple sessions can be processed concurrently. I don't know if anyone else's scenario would allow it or not, but you can have session A and session B being processed concurrently because what matters is that the messages for those sessions are processed by a single receiver in the order they were sent. I think that's the key point.

What it means for NSB is that the concurrency number would be translated into concurrent sessions a single instance of an endpoint can handle.

[DavidBoike]

Thanks @SeanFeldman! That provides more context that might allow a future Azure enhancement process to pick this up, but unfortunately I still can't promise any sort of timeline.

[SzymonPobiega]

Hey!

We are starting to investigate this feature. So far we established that when sessions are used natively with Azure Service Bus SDK, when a message is DLQ-ed (because it has been abandoned a number of times), ASB immediately makes the next message in the session available for processing. This seems to break the ordering guarantee.

How are you folks dealing with that limitation? We think that the same issue would affect delayed retry mechanism that is based on scheduled messages.