Azure-docs: Session life cycle

[vhe1]

Hi!
I would like to see a bit more on the life cycle of a session in the message broker. The problem I have is that on the one hand, you write:

On session-aware queues or subscriptions, sessions come into existence when there is at least one message with the session's SessionId. Once a session exists, there is no defined time or API for when the session expires or disappears.

On the other hand, there is:

All existing sessions in a queue or subscription can be enumerated with the SessionBrowser method in the Java API and with GetMessageSessions on the QueueClient and SubscriptionClient in the .NET client.

So, if I use sessions for implementing a call/return pattern, in an application running for ten years, that SessionBrowser thing will return billions of (now empty) sessions beause every session ever opened will still be there somewhere?

Lots of Greetings!
Volker

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 0803fba3-53aa-0d6b-e692-81777f3f7641
• Version Independent ID: fdc839f6-4986-89f2-5334-879559df8511
• Content: Azure Service Bus message sessions
• Content Source: articles/service-bus-messaging/message-sessions.md
• Service: service-bus-messaging
• GitHub Login: @clemensv
• Microsoft Alias: spelluru

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[asergaz]

Hello @vhe1 thank you for your very pertinent question. I assigned the author of the document @clemensv for further clarification.

It would help us if you can share with us more details of your use case scenario.

Thank you!

[vhe1]

There are scenarios where lots of sessions are created, like with call/return, where I send a message to a service via queue, containing the id of a session I listen to in its Message.ReplyToSessionId, then I listen on a sessioned queue for the response.

Given all the multithreading, scaling and reboot/migrate stuff in a modern web hosting, I really see no other way to implement a call/return using anything other than random guid session id's , i.e. one per call.

In a busy web application, there can be hundreds of such api calls per minute or even second, and millions over years, adding up to an equally large number of sessions.

So, can I use a new guid for each call or will I run out of sessions? What does the SessionBrowser object return after a few years of running?

Will a session use resources, i.e. _any_ resources, whether storage, or even a list of session id's or anything at all if there are no messages in there?
Or is a session

• without messages
• with sessionstate==null
• with no one listening for messages in this session

fully equal to a session that does not exist yet? Does it actually _exist_?

[CasperZBang]

I have the same concern.
For each Document we would have multiple messages, that needs to be individually handled in sequence.
Therefore the SessionId would equal the DocumentId, of which there are millions every year.

Will we run into problems when we a few years in the future have millions of different SessionIds used, where most of them are old and empty and will NEVER have new messages pushed to them again?

[jwisener]

@sergaz-msft I wonder why no one at ms never responded to these questions

[axisc]

@vhe1 If there are no active messages for a session, then that session does not utilize any resources on the service side.

it will not show up when queried using the SessionBrowser also.

please-close