search

Azure / azure-sdk-for-go

This repository is for active development of the Azure SDK for Go. For consumers of the SDK we recommend visiting our public developer docs at:
https://docs.microsoft.com/azure/developer/go/
MIT License
1.56k stars 801 forks source link

Service Bus: Support for push-based messaging #16939

Open bvwells opened 2 years ago

bvwells commented 2 years ago

Feature Request

It would be good to have support for push-based messaging in the new Service Bus client. At the moment the lack of this functionality makes migration from https://github.com/Azure/azure-service-bus-go to this new client more involved than need be.

Reading the migration document here it seems that it has been a design decision to not support push-based messaging. It would be interesting to know whether this is the case and what the rationale for it was. If it is not the case, it would be useful to know when this functionality is likely to come.

richardpark-msft commented 2 years ago

Hi @bvwells, thanks for taking the time to file an issue!

It would be good to have support for push-based messaging in the new Service Bus client. At the moment the lack of this functionality makes migration from https://github.com/Azure/azure-service-bus-go to this new client more involved than need be.

I'd be interested in this. There is definitely a difference but, for me, the migration was typically just moving the contents of the callback into the body of a for loop.

I want to make that as easy for people as possible so I'd love to get any feedback from you about what kind of things you had to do. This could be a total conceptual miss on my part, appreciate any information you'd be willing to provide.

Reading the migration document here it seems that it has been a design decision to not support push-based messaging. It would be interesting to know whether this is the case and what the rationale for it was.

Keeping the SDK small gives us time to get feedback from people and design the next phase. There's a lot of activity on push-based messaging design in C# and Java, which we'll be taking into account as well.

On the other side, the equivalent ReceiveMessages() implementations in other languages (C#, Java, JS) are generally well received and easily understood, which made it a good candidate for our first release as a primary API.

ghost commented 2 years ago

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

bvwells commented 2 years ago

Thanks @richardpark-msft for the reply on this. I guess notionally it is just a loop over the ReceiveMessages. There is probably also some handling of error conditions to take care of. At the moment I don't quite know the error conditions of ReceiveMessages and when an error is retryable. Probably need to do some digging on this.

From ease of conversion to this SDK it is a little bit of a pain. We typically use a handler type pattern to adapt from receiving messages to executing our domain code. As the existing handlers have a signature like func (ctx context.Context, msg Message) it means we now have to write more adaption as the completing/abandoning/... of the message is no longer done through the message, but through the receiver.

I'm also interested in being able to set client side receive settings for this to be able to control aspects such as the level of concurrency for processing messages. This is something which is perhaps easier to do by registering a hander function which can be executed concurrently. This type of functionality is available in other messaging SDKs and could be a nice addition.

richardpark-msft commented 2 years ago

Thanks @richardpark-msft for the reply on this. I guess notionally it is just a loop over the ReceiveMessages. There is probably also some handling of error conditions to take care of. At the moment I don't quite know the error conditions of ReceiveMessages and when an error is retryable. Probably need to do some digging on this.

One thing we've done in the SDK is try to make this kind of error identification unneeded. Most errors, by the time they land in user code, mean "this entire thing is dead". So the only remediation at that point would be to print the error and restart the connection entirely. Ie, if an error has finally come back recovery just plain wasn't possible.

We allow configuration of this via the azservicebus.RetryOptions, which you can pass into NewClient() in the most recent version of azservicebus. This will let you pick your tolerance for how much you want to retry, etc... This will take care of properly classifying and doing the proper recovery which should hopefully save you from having to write that code.

From ease of conversion to this SDK it is a little bit of a pain. We typically use a handler type pattern to adapt from receiving messages to executing our domain code. As the existing handlers have a signature like func (ctx context.Context, msg Message) it means we now have to write more adaption as the completing/abandoning/... of the message is no longer done through the message, but through the receiver.

This one is less "hander-vs-receivermessages", and more just a design choice we've made across all the SDKs. The gist of it is to avoid having 'activerecord' style models and instead stick to having 'actions' be on the clients. There is some affinity with the receiver as well when we settle messages.

I'm also interested in being able to set client side receive settings for this to be able to control aspects such as the level of concurrency for processing messages. This is something which is perhaps easier to do by registering a hander function which can be executed concurrently. This type of functionality is available in other messaging SDKs and could be a nice addition.

This one is certainly interesting, and it's one area where I'm observing how well our Processor implementations (callback based) have gone with customers in other languages. The "glue" areas, where they control concurrency or do implicit calls, seem to be causing some issues and I want to take those into account if/when we add a Processor into Go.

richardpark-msft commented 2 years ago

(moving into backlog as this isn't going to happen for GA)

github-actions[bot] commented 3 months ago

Hi @bvwells, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.