-
Notifications
You must be signed in to change notification settings - Fork 48
Update to Azure Service Bus 5 #4821
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
Conversation
- By default uses migration topology with budnle-1 topic - Can override the single topic via connection string - Can provide custom topology options via ServiceControl.Transport.ASBS/Topic setting
…opic explicitly specified
- Connection string has precedence over custom config
|
@danielmarbach I pushed the latest approach that takes advantage of |
src/ServiceControl.Transports.ASBS/ServiceControl.Transports.ASBS.csproj
Outdated
Show resolved
Hide resolved
src/ServiceControl.Transports.ASBS/ServiceControl.Transports.ASBS.csproj
Outdated
Show resolved
Hide resolved
|
Approving but we should probably wait with merging until we have the final version right? |
That is a HUGE breaking change. Please don't make that the default! It would break any subscribers to SC events if these would not be using the new topology. As SC needs to be wirecompatible with prior Core versions you can't make this the default without explicit consent. Another option is explicit opt-in during upgrade OR make hybrid the default. Please don't do a hidden breaking transport change. |
Azure Service Bus transport 5 introduces new event delivery topology using topic-per-type approach. This change affects how ServiceControl publishes integration events.
Behavior:
TopicNameproperty, ServiceControl uses the migration topology that allows publishing events in the way they can be processed by older versions of the transportServiceControl.Transport.ASBS/Topologysetting. This option allows mixing topic-per-event and single-topic approaches if there are subscribers that use both versions