[FEATURE REQ] Support GetMessageSessions

[miqm]

Library name

Azure.Messaging.ServiceBus

Please describe the feature.

Hello,

Please reopen #20569. This is fully doable with Azure Service Bus AMQP transport. As per discussion here: MicrosoftDocs/azure-docs#119766 and implementation in Java SDK: https://github.com/Azure/azure-sdk-for-java/blob/6c697512988fbd96a9d8a9bfe84eb96566f4681b/sdk/servicebus/microsoft-azure-servicebus/src/main/java/com/microsoft/azure/servicebus/SessionBrowser.java#L37 setting maximum value for the last-updated-time field returns all sessions in the response.

[jsquire]

Hi @miqm. Thank you for reaching out and we regret that you're experiencing difficulties. This is not a feature that we can consider at the present time, as the service API does not behave in an intuitive and consistent way that would address common developer scenarios. The example that you're referencing works only when a developer has explicitly created state for a session, which is a seldom used feature. It also does not filter sessions that have no active messages, making it misleading for the commonly requested use case.

For this to be something that we can add to the client, service changes are needed to correct the behavior. The Service Bus team has indicated that this is not on their roadmap currently. I'm going to close this issue out; should the service offer an API with the expected behaviors, the client will support it.

If you would like to advocate for service support, consider opening a feature request in the Service Bus forum of the Azure feedback site.

[github-actions]

Hi @miqm. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[miqm]

The example that you're referencing works only when a developer has explicitly created state for a session, which is a seldom used feature.

@jsquire I raised that concern in MicrosoftDocs/azure-docs#119766 and @yvgopal (Microsoft employee) corrected that providing DateTime.MaxValue returns ALL sessions - with sessions state set and not set. This is a consistent way I think and fits scaling scenarios.

I think that there's some misunderstanding and that feature does exist in Service Bus. Basing on the Java SDK - since quite a long time...

/unresolve

[miqm]

It also does not filter sessions that have no active messages, making it misleading for the commonly requested use case.

I wouldn't consider this as a blocker. You would get session only if a state is set and as you said - this feature is used seldom.

[jsquire]

Thank you for your thoughts but, as mentioned, this is not something that we'll consider adding without changes to the service API. We have reviewed the service API extensively with the Service Bus service team; there is no misunderstanding, and the Java example that you are using has the limitations that I've mentioned above.

[github-actions]

Hi @miqm. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[miqm]

Limitation with filtering or not getting all sessions?

[jsquire]

At a minimum, the service API would need to return all sessions regardless of whether or not state was set. It should allow callers to filter by whether or not there are messages in the session.

[miqm]

At a minimum, the service API would need to return all sessions regardless of whether or not state was set.

This is doable today, correct?

[jsquire]

No, it is not. Vijaya's statements are incorrect with respect to the current service behavior. The Azure SDK team has discussed this internally with him and the other members of the Service Bus service team. They have confirmed that it requires session state to have been set in order to return the session and stated that adjusting the behavior is not currently on their roadmap.

[miqm]

@yvgopal could you comment on this please? I'm a bit confused...

[jsquire]

//cc: @EldertGrootenboer

This request is coming up again.

For historical context:

• GetMessageSessions in a queue azure-service-bus#275
• Consider supporting list sessions feature #11439
• [FEATURE REQ] Get Session Information for a Queue/Subscription - Azure.Messaging.ServiceBus #20569

[miqm]

Also some context: kedacore/keda#1479
Cc: @tomkerkhove

[miqm]

No, it is not. Vijaya's statements are incorrect with respect to the current service behavior.

@jsquire I tested this on my Service Bus instance and when I provided timestamp value as @yvgopal suggested - in the AMQP response I received list of sessions with both state set (and no messages) and those that exist only due to existence of a message in the queue. So unless there's something non-deterministic going on, it seems to be working.

[github-actions]

Hi @miqm, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.

[miqm]

/unresolve

[jsquire]

I'm going to close this out in favor of #275. While we appreciate the discussion and the anecdotal evidence, the fact remains that the Service Bus team has not signed off on the feature providing the necessary behavior and committed to supporting it as such. Until that takes place, this will not be added to the Azure SDK packages.

@EldertGrootenboer: As the product owner for Service Bus, I'll ask that you reactivate 275 if the service is reconsidering the request or that you reach out if the status has changed since our last conversation.

[miqm]

This is very odd. One team says it does not exist, second is updating official documentation. Please get it straighten.

[miqm]

Will the #275 be re-opened?

[jsquire]

Will the #275 be re-opened?

The fate of 275 depends on the decisions made by @EldertGrootenboer and the Service Bus team.