In an Azure ServiceBus session enabled subscription why do I receive messages with the same session id on multiple subscriber instances

Question

I have a session enabled subscription on a service bus topic and have four subscription clients running against this subcription.

I publish 10000 messages across 100000 random sessions to the topic and looking at my output I can see multiple subscription clients processing messages for the same session id within seconds of each other, i.e.

SessionId	Client A	ClientB
1234	processing at 10:30:04
1234		processing at 10:30:29
1234	processing at 10:31:00

This was done with the session idle timeout default of 60 seconds.

I then set the session idle timeout to a 2 second timespan. Each SessionProcessor has 100 MaxConcurrentSessions and has AutoCompleteMessages set to false.

I am also observing a lot of errors for "The session lock was lost".

When I receive a session lock exception that session is then started on a different client and the same message is processed on the second client that had already been processed on the client with the session lock exception.

My question is, do I need to record processed message id's before attempting to call CompleteMessageAsync on the ProcessSessionMessageEventArgs so I can then check it for every single message being consumed to avoid processing it again or is there a reason I'm unaware of for my session to lose the session lock - does this happen when the session idle time has been surpassed before calling CompleteMessageAsync?

This is all in test code so my processor is simply writing to the console and doing non long running tasks.

Answer 1

When using a topic, messages are copied and forwarded to all subscriptions, in which the session would be visible for receivers.

If you don't want all receivers to process each sessions, then you should just use a single queue with all receivers listening on it. Then each session and its set of messages would be processed only once, by one of the receivers.

Answer 2

I was scaling out and therefore had multiple instances of my client listening on a single subscription.

The issue seemed to happen when I increased the maximum number of concurrent sessions, Azure Service Bus didn't seem to be able to handle it. If I remember rightly it was processing fine with around 750 max concurrent sessions.

This was far above what I needed so I implemented a message log for checking duplicate messages and then when I received a session lock lost exception on Ack'ing the message and it was redelivered I checked the message log and if already processed I would simply Ack the message.