[QUERY] ServiceBusProcessor/SessionProcessor client - apis to accept specific session, receive deferred messages, peek message using sequence number

[manishtulsiani]

Query/Question This issue is created based out of a comment on an earlier issue referenced earlier here. Tagging @lmolkova as she has contextual information about the issue.

The ServiceBusProcessor/SessionProcessor client is the client generally recommended by MSFT in most cases as it comes with high throughput, reliability, error recovery etc. However this client is lacking in feature parity with the lower level receiver/session receiver and their async reactor counterpart clients in terms of the following capabilities

• accept a specific session: available in lower level sync/async client here.
• peek messages: the lower level clients can peek messages which can be used to get back deferred messages (via finding their sequence number). The received message context from processor client supports defer but the client itself does not support peek through messages which is required to find deferred messages if the application loses track of sequence numbers.
• receive deferred messages - once a message has been deferred the only way to get it back is through the sequence number. the processor client does not have such a feature which requires creating the lower level clients.

The ask is to know if MSFT is planning on bringing the processor client to feature parity with lower level receiver clients. The primary reason being it will simplify end users to use only 1 type of client (processor/session processor) for all service bus operations that they may require so that they can take advantage of the simplicity and resiliency features of processor client. Creating the lower level clients works but brings added complexity.

Why is this not a Bug or a feature Request? This is a feature request or a question to know if MSFT is planning to support some/all/none of the feature discrepancy between processor and lower level receiver client.

Setup (please complete the following information if applicable):

• OS: [e.g. iOS] N/A
• IDE: [e.g. IntelliJ] N/A
• Library/Libraries: [e.g. com.azure:azure-core:1.16.0 (groupId:artifactId:version)]: currently using azure-messaging-servicebus:7.15.2

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [x] Query Added
• [x] Setup information Added

[github-actions[bot]]

@anuchandy @conniey @lmolkova

[github-actions[bot]]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[conniey]

Hey. Those are good questions. I'll take a look and get back to you.

[conniey]

The session ids are something we overlooked. The Service Bus Processor was designed to facilitate processing all messages from a Service Bus entity, but is not intended as a replacement for the lower level clients. Could you speak more to the user scenarios around wanting to peek messages and receive deferred messages while using the Service Bus Processor client?

[manishtulsiani]

Hi @conniey , the scenario around message deferral that we have is when we want to trigger a long running operation upon receiving a message. For example consider the sequence of steps below as a use case for processing a very large file:

1. a large file to be processed is uploaded to storage account
2. a message is received on an input topic to process the file
3. the java app that is listening to this subscription, receives the message, knows from the payload that this operation is to process file so it may take some time. it defers the message to avoid any issues with message lock lost/redelivery etc. the sequence number is saved.
4. the app processes the file
5. once done, it receives the message with the sequence number, gets the message and immediately completes or dead-letters it depending on the result of file processing.

this is one use-case but the base premise of the use-case is when we want to trigger a long running operation upon receiving a message.

also, I think if the processor client is designed to only process all messages by receiving them, then the processor client should not expose defer apis from the received message context. Having the ability to defer but not the ability to get back the deferred messages in the same client seems an inconvenience to the end users as the end users would then anyway have to use processor and a lower sync/reactor async client which complicates the code imho.

we have this working with the lower level clients, the ask is more specifically to see if MSFT would consider supporting all features in 1 client namely the processor since it is the client most recommended to be used in various documentation and whenever we have opened support cases.

Thanks.