Adding subscription rules is very slow.

[mattdone01]

Checking and adding subscription rules when connected to Azure service bus is very slow. This is due to the fact that there is no way to check if a rule exists and you have to handle and exception to add the rule. Microsoft has just approved and committed a pull request Azure/azure-service-bus-dotnet#192 that should fix this issue.

The code is at Line 82 of AzureServiceBusForwardingSubscriptionCreator. MS have now added GetRulesAsync() which should remove the need to handle an exception for an add. Can someone please confirm my assumptions is correct. Thanks

[SeanFeldman]

@mattdone01 the referenced PR is still a WIP. Also, that client is the new client (Microsoft.Azure.ServiceBus) that has not GA-ed yet 🙂 NSB.ASB transport is using WindowsAzure.ServiceBus.

[SeanFeldman]

For the current client, I've raised an issue with the PG.
Will be more than happy if you'd thumb it up and so your comment as well.

[mattdone01]

Hi Sean, Is there a path to upgrade NSB.ASB transport to the new Microsoft.Azure.ServiceBus library. It went RC1 the other day. I'd be happy to help out if required.

[SeanFeldman]

Thank you @mattdone01. Very kind of you to offer help and it's appreciated.
The path to upgrade is not as straight as we'd like it to be. First, there's not support for SendsAtomicWithReceive transport transactions. It's only going to show up in the 2.0.0 of the new ASB client. In addition to that, there are other things that stay in the way, such as no support for HTTPS connectivity mode. And there's also a very significant issue that will affect wire compatibility NServiceBus cannot break.

Given all these, the upgrade is unfortunately not a simple update. We're looking into the options internally to ensure that we enable our customers to be able to run on the new client w/o compromising trust and support of the existing customers that expect things to work w/o surprises.

A side note on RC1 - be careful if you intend to use it in production. It is not a final version and there will be issues that would need to be resolves (like this one, or this one, or this one).

[mattdone01]

Thanks Sean. Appreciate the response. When we start a console it takes about 2 minutes to start up as we have about 25 event handlers (CQRS implementation). I've debugged the NSB code and the bulk of the time is taken when checking for the existence of a rule (It throws an exception to check existence). I know it's not the best code but I don't suppose we could get a flag to bypass any rule check. Something like transport.ByPassRuleCheck with it obviously set to false as the default. That would be a big help. Thanks Sean.

[SeanFeldman]

Is disabling installers and scripting your entities a viable option?
(Removing endpointConfiguration.EnableInstallers(); from your configuration code).

[danielmarbach]

And run without managed rights if you're topology doesn't change that often. This will bypass all those checks as well. See https://github.com/Particular/NServiceBus.AzureServiceBus/blob/develop/src/Transport/Topology/TopologyCreator.cs#L34

[mattdone01]

Hi Daniel,
Thanks for that. How do you set NSB to "run without managed rights". Thanks.
Matt

[danielmarbach]

I'm assuming here you are using Shared access policies. Create a new policy and do not grant the manage rights and use that in the connection string.

[mattdone01]

That just throws an "UnauthorizedAccessException" : 'Topology creation requires manage rights, but no manage rights could be found for the following namespace(s): default' and the bus fails to start.

[danielmarbach]

You need at least this version

https://github.com/Particular/NServiceBus.AzureServiceBus/releases/tag/7.2.3

and you need to disable the installers (remove EnableInstallers()) from your configuration. Does that work?

[mattdone01]

I am using NServiceBus.Azure.Transports.WindowsAzureServiceBus.7.2.6
With the following Config
` var configuration = new EndpointConfiguration(UniqueQueueAddress.EndpointName());
var assemblyScanner = configuration.AssemblyScanner();
assemblyScanner.ExcludeAssemblies("PostSharp.dll");

        configuration.UseContainer<AutofacBuilder>(customizations =>
        {
            customizations.ExistingLifetimeScope(container);
        });
       
        NServiceBus.Logging.LogManager.Use<NLogFactory>();

        configuration.SendFailedMessagesTo("error");
        configuration.UsePersistence<InMemoryPersistence>();
        configuration.UseSerialization<NewtonsoftSerializer>();
        //configuration.EnableInstallers();
        var transport = configuration.UseTransport<AzureServiceBusTransport>();
        transport.ConnectionString(ConfigurationManager.AppSettings["ServiceBus.ConnectionString"]);
        transport.UseForwardingTopology();
        transport.Transactions(TransportTransactionMode.ReceiveOnly);
        var sanitization = transport.Sanitization();
        sanitization.UseStrategy<CustomSanitizer>();

        configuration.Conventions().DefiningEventsAs(type => type.Namespace.StartsWith("CurrencyVue.Domain.Events"));
        configuration.Pipeline.Register(new ContextBehaviour(), "Provides static access to current IMessageHandlerContext");

        return configuration;`

[danielmarbach]

@mattdone01 Did you run without the debugger attached? When the debugger is attached for convenience reason we always execute the installers

[mattdone01]

Yes I did. The problem I am trying to solve is the amount of time a debug console takes to load when there are a lot of event handlers (up to 2-3 minutes). Am I able to opt out of the "always execute the installers in debug mode convenience feature"? When you are start a debug console 10 times a day this gets to be an annoying time waste, almost to the point where we are looking at alternatives to NSB and ASB. Thanks.

[danielmarbach]

@mattdone01 I raised an issue in NServiceBus. We will also investigate into why it takes so long.

[danielmarbach]

With LOG DEBUG enabled, 30 handlers for 30 events and debugger attached

Start clean:

• 00:00:25.9581129
• 00:00:25.0643197

Restart:

• 00:01:13.3926295
• 00:01:13.5702365

Quite insane you are right @mattdone01

Will investigate more. Sample used
multiple-subscribers.zip

[danielmarbach]

A preliminary first investigation shows that we can improve a lot here.

• Topology section creation can be done concurrently
• Starting receivers in a Parallel.For is very expensive (as discussed months ago) and a synchronous blocking operation which actually does not need to be awaited

Will continue to investigate tomorrow and send in a few PRs as discussion points.

[danielmarbach]

@mattdone01

I raise the following issues

#597
Particular/NServiceBus#4897

The core fix would already give you a really decent boost. I'm trying to get this in asap

[mattdone01]

Thanks for all your help @danielmarbach. My team really appreciates it.

[danielmarbach]

@mattdone01 I created a custom release build for you. It looks like the fix will take a few more days but the custom build should get you into a more decent situation regarding the startup behavior. Please try it out and see what it gives.
ConcurrentSubscription.zip

[mattdone01]

Hi @danielmarbach , that patch makes start times considerably better now. We are down to about 15-20 seconds, which is pretty good. Thanks for your help on this. Let me know when it makes it in a GA release.

[janpieterz]

@danielmarbach is this similar to #522? If so, it sounds like we're about to cut our deployment times in half when this gets out 🙌

[danielmarbach]

@janpieterz yes the root cause is what we have fixed. Feel free to use the above custom build and tell me what happens 👯‍♂️

[janpieterz]

I'm on holiday so won't be able to for a while, but will mark this as to confirm, unless it'll be pushed into GA in the meantime.

[danielmarbach]

6.4 is out which contains the fix https://groups.google.com/forum/#!topic/particularsoftware/fsNiiUJwwdc

Closing this.

[danielmarbach]

Btw. in 6.4 it is now possible to Disable the installers to run without manage permissions even with the debugger attached

[janpieterz]

Great (startup and therefore deployment) speed improvement here! Thanks @danielmarbach

[danielmarbach]

@janpieterz 🙇 thanks for giving feedback. Always appreciated!