With NSB 8 I'm getting ServiceBusException: Cannot allocate more handles. The maximum number of handles is 255

21

Hi Remy,

How is your system going? Is it still stable after this change?

Mike

22

Hi @MikeMinutillo,

It’s very stable. No issues anymore related to this. Also, the duplicate diagnostic entries are not happening anymore.

Thanks for the help!

1 Like
23

Hi @remyvd,

we are investigating potential improvements to our serverless configuration API. This conversation came onto our radar.

Do you remember the reason why you were using UseTransport API? Were you looking for some specific configuration setting unavailable on the serverless configuration?

24

Hi @tmasternak,

The reason is that I have centralized the configuration of endpoints and was calling the helper method (=extension methods).

After this issue I changed the code for configuring the endpoints. It now looks like:

[assembly: NServiceBusTriggerFunction("%ENDPOINT_NAME%", TriggerFunctionName = "NServiceBusTriggerFunction")]

Console.Title = "AV.Spotler.FunctionHost";

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureEndpointDefaults()
    .ConfigureAppConfiguration((context, builder) =>
    {
        builder.AddUserSecrets<Program>();
    })
    .UseNServiceBus((configuration, endpointConfiguration) =>
    {
        endpointConfiguration.AdvancedConfiguration.ConfigureEndpointDefaults(configuration, false);
        
        // endpointConfiguration already has transport configured with ServiceBus so configure directly
        endpointConfiguration.Transport.ConfigureEndpointDefaults();
        endpointConfiguration.Routing.RouteToEndpoint(typeof(RetrieveAndSyncContactToSpotler).Assembly, "AV.Dataverse");
        endpointConfiguration.Routing.RouteToEndpoint(typeof(SyncContactToSpotler).Assembly, "AV.Spotler");
    })
    .ConfigureServices((context, serviceCollection) =>
    {
        serviceCollection.AddNamedHttpClientsWithOAuth1ForSpotlerClient();
        serviceCollection.AddAutoMapper(typeof(ContactProfile));
    })
    .Build();

host. Run();

I still need to configure the transport, because of the subscription (rule) naming convention.

    public static void ConfigureEndpointDefaults(this AzureServiceBusTransport transport)
    {
        transport.SubscriptionNamingConvention = SubscriptionNamingConvention;
        transport.SubscriptionRuleNamingConvention = SubscriptionRuleNamingConvention;
    }
    
    static Func<Type, string> SubscriptionRuleNamingConvention => t => t.FullName!.Length <= 50 ? t.FullName : t.FullName.Substring(t.FullName.Length - 50);

    static Func<string, string> SubscriptionNamingConvention => n => n.Length <= 50 ? n : n.Substring(n.Length - 50);

Personally I think you NServiceBus should just set good defaults for the naming conventions, based on the transport type, so I don’t need to do this.

25

It used to. But what’s good for one client is not ideal for another. And finding a middle ground is damning. That’s why the end-user needs to select a strategy for naming and configure their conventions. What I agree about us that there could be some baked-in strategies that could be enabled with an opt-in configuration. For example: rules names using event name over full name (with a namespace) if your organization doesn’t care about namespaces and event names are unique.

1 Like