opened
JoshLove-msft
username_0
We currently return a ServiceBusReceiver whether you call client.GetReceiver or client.GetSessionReceiver. The sessionManager holds the session related functionality. This was part of our initial design before we switched to using a top level client, as it avoided forcing users to know that they needed something like a SessionClient to do anything when working with sessions. 

With the current design, a user will always start by creating a ServiceBusClient and then calling GetReceiver/GetSessionReceiver depending on whether they are using sessions. As such, we may as well just have GetSessionReceiver return a different type that derives from ServiceBusReceiver, and do away with the concept of a SessionManager entirely.
Consider introducing a SessionReceiver instead of a SessionManager
issue
created
hemanttanwar
username_1
Although this willreduce one  type `sessionManager `  but if  you `return a different type that derives from ServiceBusReceiver` , this new type will also have `RenewMessageLockAsync` function . You can not reduce the visibility of this function in   new SessionReceiver .
comment
created
JoshLove-msft
username_0
You are right that we still would need to throw an exception if a user attempts to RenewMessage lock from the session receiver. But this isn't a new issue as we already have to do this.
comment
created
JoshLove-msft
username_0
So one thing that I didn't think of initially.. The callback for the processor takes an EventArgs which has a Receiver property. If we do this change users would need to downcast this property to a session receiver to access the session methods.
comment
created
richardpark-msft
username_2
@username_0 - some of these difficulties are "gone" when the settlement methods end up on the Message object itself, rather than on the client.

1. Messages can be settled directly w/o a receiver. Callback gets simpler.
2. Renewing a message lock goes on the Message object, so no need to worry about differences on the client.

FWIW, JavaScript is doing both of these - settling methods on the message and two receivers (Receiver, and SessionReceiver (derived from Receiver)). This lets me avoid having a .Session or any other weirdness altogether.
comment
created
JoshLove-msft
username_0
@username_2  how do you do session operations from the callback?
comment
created
richardpark-msft
username_2
@username_0  - Those are on the receiver.
comment
created
JoshLove-msft
username_0
For concurrent receiving I believe the session operations would need to be available within the callback as the outer SessionReceiver would not have the appropriate receive links for each received message.
comment
created
richardpark-msft
username_2
I think you're right - the session manager aspect still needs to be designed.

In JS I think it's going to end up being a separate class altogether so we don't have to have the same exact interface on the typical Receiver interface and the "round-robin-receive" interface.
comment
created
JoshLove-msft
username_0
Yeah another idea that @KrzysztofCwalina floated was having any actions that a user would be reasonably expected to take in the processor just be methods directly on the EventArgs, so we wouldn't have to include the entire Receiver.
comment
closed
JoshLove-msft
username_0
issue