NServiceBus.Transport.AzureServiceBus
NServiceBus.Transport.AzureServiceBus copied to clipboard
Particular
Add support for message sessions
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.
@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?
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.
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.
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.
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.
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?
No new information yet. But we appreciate the comments. They help us determine what people are asking for to help with prioritization.
