search

Particular / NServiceBus.AzureServiceBus

The Azure ServiceBus Transport
https://docs.particular.net/nservicebus/azure-service-bus/
Other
13 stars 17 forks source link

Support WindowsAzure.ServiceBus v5.0 #724

Closed danielmarbach closed 6 years ago

danielmarbach commented 6 years ago

Build: 3.0.51272.9 • General: This is a major version update because of .Net Framework dependency change: target framework is now .Net 4.6. • General: Fix a potential process crash when canceling the HttpWebRequest associated with the WebSocket. User can hit this condition when running large client instances using one of the non-tcp mode in Microsoft.ServiceBus.ConnectivityMode. • EventHub: EventHub: Fix a bug where client using an IoT connection string and called GetRuntimeInfo Api, the call is made using incorrect security token after connection redirect. (as described in 4.2.2-preview, build 3.0.51093.5) • EventHub/Messaging: Added support for Role-Based Access Control and Managed Service Identity. • EventHub/Messaging: Fix a potential null ref exception generated in race condition in Amqp close() code path. User can hit this condition in a rare race in high throughput scenario. • Messaging: Add transaction support in MessageSession Get/SetState API when using Amqp as transport. Amqp transport now fully support transaction in Messaging APIs. • Relay: Reduce allocations in WebSocket. (as described in 4.2.1-preview, build 3.0.51093.4) • Relay: Add E2E Activity correlation and include TrackingId in more exception messages. (as described in 4.2.1-preview, build 3.0.51093.4)

SeanFeldman commented 6 years ago

Given that v5 is out of support, what's the context @danielmarbach

danielmarbach commented 6 years ago

Like the title says it is about https://www.nuget.org/packages/WindowsAzure.ServiceBus/5.0.0

SeanFeldman commented 6 years ago

👍 Full support for AMQP finally

dbelcham commented 6 years ago

@SeanFeldman @danielmarbach with my KtLO hat on: what is the expectation with this new release? Would you just be bumping the version of the dependency or would you also be looking to add features to the transports/persistence based on the new features in this version of the SDK?

yvesgoeleven commented 6 years ago

@dbelcham just bump version, we agreed to release new features in new transport only

SeanFeldman commented 6 years ago

What @yvesgoeleven said 🙂

dbelcham commented 6 years ago

@yvesgoeleven @SeanFeldman @danielmarbach A few questions to help KtLO figure out the priority of this

  1. Am I correct in assuming that the bug fixes above are only those that affect the bits of the SDK that we use? If so, are any of these bugs that our customers are encountering?
  2. What will happen for our customers if this isn't upgraded right away?

A somewhat separate question that popped up, do our customers normally reference parts of this SDK in their apps for reasons other than using NSB? i.e. Their app uses NSB+ASB and also has code to use some Azure component, like storage, or DNS, or...anything, exposed by the SDK

yvesgoeleven commented 6 years ago

@dbelcham

  1. Am I correct in assuming that the bug fixes above are only those that affect the bits of the SDK that we use? If so, are any of these bugs that our customers are encountering?

Only the following bugs can be encountered by our usage, but I haven't had any reports of this happening.

do our customers normally reference parts of this SDK in their apps for reasons other than using NSB?

This SDK is also used for Eventhubs and Relay scenario's. NSB doesn't use this part, but customers could be using it for sure.

  1. What will happen for our customers if this isn't upgraded right away?

It would prevent our customers from leveraging the new features. The following feature is particulary enticing for many enterprises, I suspect it will be in demand:

No code changes are required from our part, we already have the right hook to inject these tokenproviders, just opening up the allowed version range (and testing it) should be sufficient so users can hit the nuget upgrade button and inject the tokenprovider.

dbelcham commented 6 years ago

@yvesgoeleven

It would prevent our customers from leveraging the new features. The following feature is particulary enticing for many enterprises, I suspect it will be in demand

Have we had any reports of customers wanting to use these new features but not being able to?

yvesgoeleven commented 6 years ago

@dbelcham Not that I'm aware off, those features are fairly new. But they make life a lot easier so I assume the questions will come

SeanFeldman commented 6 years ago

Have we had any reports of customers wanting to use these new features but not being able to?

Yes @dbelcham. Shared with the squad here.

SzymonPobiega commented 6 years ago

Would assembly redirects be a decent workaround so that we don't need to fix it urgently?

yvesgoeleven commented 6 years ago

@SzymonPobiega our nuget dependency range doesn't allow to install it, that's what needs to be fixed. Once allowed a binding redirect may or may not work (probably will, needs testing)

SeanFeldman commented 6 years ago

Note: NServiceBus is still targetting net452. By updating to version 5.x of the ASB client, we'll force to upgrade to net46.

SeanFeldman commented 6 years ago

Fixed via https://github.com/Particular/NServiceBus.AzureServiceBus/commit/c80c02087ec1403b14679bb829a65375a42568d2