-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure Service Bus Custom Consumer #1571
Comments
@yang-xiaodong |
@mviegas What do you think about this feature? |
It makes sense to me. I always envisioned such a feature. It provides more flexibility in the pub/sub configuration in similar ways to other libraries, such as MassTransit. A couple of things that come to my mind are:
|
@mviegas Thanks for the quick response.
I hope that is what did you expected |
Thanks for your prompt reply @KuchaD. I think I might have misread what your suggestion was. So we're not going deep on a type level, but rather on a topic (group) level. I have to think a bit more just to make sure we deliver a coherent and long-lived API for this, if you could give me a couple of days to reflect on it before a final decision it'd be great. Meanwhile, I will start the code review in the PR for what's currently there, it's a great kickstart. |
Another question that comes to my mind: are you proposing to support multiple topics within a single namespace? Or multiple topics in multiple namespaces? If the latter is the answer, what is the motivation behind it? |
@mviegas I already processed review comments. We have realy lots of microservice and where microservisea has topic for single type message. Example: Service A with namespace NA Service B with namespace NB Service C with namespace NC |
Hi @KuchaD! Thanks for your feedback. After some more thorough thoughts, I have no issues with the approach of producing/consuming multiple topics within the same namespace. However supporting multiple namespaces would mean supporting multiple broker addresses, which is something that goes against current CAP contracts and would also introduce a lot of background work not only in the transport layer but also in the framework itself to ensure proper connection management (multiple topologies, resiliency, etc.). cc @yang-xiaodong That way, I think that we can move forward with the approach of adding custom topic consumers for the same namespace, but not for multiple namespaces. In practice, this would mean that every ConsumerDescriptor as proposed in #1572 should only have Entity-related properties (like EnableSessions, message TTL), not Namespace-related properties (like Connection String/Credentials). |
@mviegas Hi I understand your problems because you use BrokerAdress in ConsumerRegister. But if you use TokenCredential dont you need BrokerAdress ? What do you think when we could supported multiple namespace if we use TokenCredential ? I just quick checked imlementation. Maybe i wrong. |
@KuchaD you're right that there's a bug in the BrokerAddress setter for the ASB transport. It should be settled as either the ConnectionString or the Namespace when the authentication is done via TokenCredential. Nowadays it doesn't consider the latter. That said, the rule for connecting to a single namespace is still valid. We should keep it that way to keep the library standards with other transports as well. |
@mviegas thx for explained. Do you think that in future you will support multiple azure service bus or (namespacing) as Mass Transit. For company were i am working is it really necessary for using cap in our project. Now we have one project with cap and we really satify with them but this is big blocker for us for migrate from mass transint to cap |
I am open to contribute with this situation if you are open to help me make solution and figure out how to implement this to cap. For start i fix solution for one namespace :) thx |
@KuchaD, yes I'm aware that MassTransit allows you to configure multiple buses with some adjustments using .NET DI, where each bus has its own configuration, including the broker address/namespace. In CAP, configuring multiple buses isn't currently possible. If this changes in the future, we can adapt the ASB transport to support it. But it should be something coming from the framework first. |
Current Situation:
Currently, our Azure Service Bus provider lacks support for multiple namespaces and topics for consumers. We are utilizing a single topic within Azure Service Bus for messaging, and a single namespace for the application.
Solution Attempt:
I have attempted to implement a solution that addresses this limitation, and it works as expected. However, I am currently unable to submit a pull request (PR) for this update.
Register in program files.
Consumer
CustomConsumer
Client factory
Ctor
The text was updated successfully, but these errors were encountered: