Does NServiceBus support using Azure Service Bus sessions? The documentation looks quite extensive but I need an answer to this question before investing a lot of time reading through it all.
We have scenarios where we need both scale out AND local message ordering guarantees so we would need to leverage sessions in service bus to allow us to scale out to numerous consumers while ensuring that all messages with a given key (session id) are processed in order.
I am concerned that such transport specific features might not be supported by a framework that tries to accommodate a number of disparate messaging technologies.
Thanks.
Bill Bailey
The Azure Service Bus transport doesn’t support sessions.
Service Bus Sessions will not help you if you require both the ordered processing and scale-out. A single session can only be processed by one consumer. Multiple consumers can process multiple sessions, but messages from the same session will only be processed by a single consumer.
Without knowing the scenario can’t suggest an alternative but maybe what you’re trying to achieve can be modeled with Saga.
Thanks for the response Sean. Basically, we are looking to emulate behavior similar to how partitions are used in Apache Kafka. That is, take a stream of entity update events and consume them using multiple consumers, but provide a guarantee that at least all messages for the same entity instance (i.e. with the same id) are routed to the same consumer. We only need local ordering guarantees, not global ordering guarantees. We have had conversations with Microsoft and have a strategy for doing what we need to do with Service Bus, but we are also looking at available frameworks for putting a little bit more structure and consistency to our microservices architecture. We were looking at NServiceBus as one possible option, but needed to understand if the two things (Azure Service Bus Sessions and NServiceBus) could play together. It sounds like the answer is No … or at least not right now.
We currently use Service Bus (.NET Core MS client) and things mostly work, but because we have multiple threads processing messages from the same topic, the concurrency sometimes results in our messages being processed out of order … i.e. either lost updates or optimistic concurrency errors. This is particularly a problem when we are recovering from a Service Bus outage (even fairly short ones) because messages that were generated relatively far apart in time can sometimes be processed concurrently. Anyway, I think I think I have my answer, but if you have any thoughts, your inputs are certainly appreciated.
Thanks.
Bill Bailey