ServiceControl does not honor transport type connection string setting in Azure Service Bus

[gamblen]

Symptoms

ServiceControl 4.21.0 instances do not honor the TransportType connection string setting and always connect via TCP. If the TCP port is not open in the firewall, then instances do not read messages from their input queue, but do not log any errors.

Steps to reproduce

• Create a new ServiceControl 4.21.0 instance (primary, audit, or monitoring)
• Configure the new instance to use Azure Service Bus transport
• In the connection string, include TransportType=AmqpWebSockets
• Run the instance and use a network monitoring tool to determine which protocol is being used to connect to Azure Service Bus

Root cause

ServiceControl 4.21.0 includes an update of the Azure Service Bus transport from version 1.x to version 2.x. This version of the transport includes support for the Azure.Messaging.ServiceBus client SDK which does not honor the TransportType connection string setting.

Original details

When I updated the Service Control Monitoring instance that was pulling from Azure Service Bus, the retrieval of messages has stopped.

There are no errors in the log files, setting the logging level to Debug does not yield any further information.

I can remove the queue, or a subscription and run ServiceControl.Monitoring.exe --setup and it recreates the queue or subscriptions. This implies to me that connectivity is fine.

If I run it as ServiceControl.Monitoring.exe then the logs look like it is working, no errors, but the queue keeps getting more and more messages added from the NServicebus instances that are running.

[mikeminutillo]

@gamblen does the Monitoring tab in ServicePulse show any information?

I have just set up a new environment with Azure Service Bus and ServiceControl Monitoring 4.21 and it appears to be pulling messages from it's input queue without issue, so I haven't been able to reproduce this.

[gamblen]

@mikeminutillo Sadly not, it was that being empty that made me look at the queues.

No Monitoring data available.

So I have created a monitoring endpoint on my machine and was proxy and vpn free then it pulls fine.

The server is on the corporate network. It does have the connection string element TransportType=AmqpWebSockets, but like I said it was all working fine until the upgrade to 4.21.0, I can tell because the earliest message in the queue is around the time I did the upgrade.

So the only change I can think is causing me the problem, is 4.21.0 included an upgrade to NServiceBus.Transport.AzureServiceBus v2.0.1.

In turn that has gone from Microsoft.Azure.ServiceBus to Azure.Messaging.ServiceBus.

I will have to have a look at the documentation and see if something has slipped by unnoticed.

[gamblen]

@mikeminutillo So it looks like NServiceBus.Transport.AzureServiceBus upgrading to the new Azure.Messaging.ServiceBus meant that TransportType will be ignored in the connection string now. You have to use .UseWebSockets().

There doesn't appear from my reading of the ServiceControl code to be a way to indicate.

There is a CustomizeEndpoint method that looks in the connection string for the topic name.

I can do the change and issue a pull request. Would it be better to offer like for like as it is now, so TransportType=AmqpWebSockets would trigger the UseWebSockets()? Or something new?

[mikeminutillo]

For now, keep it the same as that will resolve the issue automatically for anyone that already has it in their connection string. I will review with the team whether there are any issues with that.

[mikeminutillo]

@gamblen your PR has been merged and released as 4.21.2. Can you update and confirm that it resolves this issue for you?

[gamblen]

@mikeminutillo applied new version, all looking good.

Thanks for you help

[mikeminutillo]

Awesome. Thanks for your contribution.