How should I be using the subscription session clients?

[jjcollinge]

I'm trying to evaluate enabling support for ASB sessions in the Dapr Azure Service Bus PubSub provider but I'm struggling to work out whether or not this is actually possible with this SDK.
Firstly to set expectations, the integration should work in a similar way to the Azure Functions Service Bus support - where the host dynamically subscribes to sessions (transparently from the user's code) and invokes the user's function (or app in the case of Dapr) in FIFO way.

AFAIK, the difficulty comes from the fact that session IDs are unbounded in space (i.e. you can have as many session IDs as you want) and in time (they never end). The SubscriptionSession can be initialized with nil to bind to a new session ID but once bound it will only receive messages on that session ID. Therefore, we would need to support multiple concurrent SubscriptionSessions to handle multiple session ids. This is fairly straight forward, except that we have to pick an arbitrary concurrency limit and we'd then be ignoring any messages for session ids outside this set. So we'd need some mechanism to release and rebind the SubscriptionSessions to new sessions using some form of fair distribution strategy (i.e. allocating fair processing time to each session id). From what I can tell (from a quick scan of the code) in the .NET SDK - they do this on a timeout basis (i.e. if a session they are listening to times out on the receive call then release the session and try another.) which I could do but it might lead to the situation mentioned above where only certain session ids are being processed (i.e. if all session ids are busy). Another possible option might be to defer the cancellation of the ReceiveOne context in the message handler so it can effectively cancel/release itself after 1 message and then bind to a new session but that seems a little hacky and inefficient.

Anyway, I was wondering if anybody had experience of doing something similar with this SDK or could offer advice on how best to approach this problem.

Thanks in advance.

[jjcollinge]

I had a quick chat with @JoshLove-msft about how this is done in the .NET SDK and it does appear they use the timeout method described above and haven't seen any issues in reality so I'm going to follow that approach for the initial implementation. I will close this issue - and only reopen if I cannot implement that pattern due to something specific to this SDK.