Feature Request: Filter predicate for predefined Hub classes in SqlServerOptions

[yp3y5akh0v]

Can you add feature to filter out specific Hub classes, so other won't be part of SQL backplane ?

[ascott18]

No, this is not the responsibility nor even the capability of an individual backplane. It also strikes me as a very unusual use case - why would you want to maintain infrastructure for multiple different backplanes?

The lifetime manager is registered as an unconstructed generic singleton with .AddSqlServer is called (or any other backplane-registering extension, like AddStackExchangeRedis). You can then (ab)use the DI system to register a more specific type for specific hubs that will take priority:

services.AddSingleton<HubLifetimeManager<ChatHubA>, DefaultHubLifetimeManager<ChatHubA>>();
services.AddSingleton<HubLifetimeManager<ChatHubB>, RedisHubLifetimeManager<ChatHubB>>();
services.AddSingleton<HubLifetimeManager<ChatHubC>, SqlServerHubLifetimeManager<ChatHubC>>();

[yp3y5akh0v]

I have 2 hubs, one where I use Groups (this is where backplane needed if I have load balancing), another just per connection which doesn't required to store shared data, also its frequently changing passing back and forth updated value. But the problem is, by default it will create backplane for every hub which is what I want to prevent.

[ascott18]

Makes sense, although do note that this SQL Server provider will short circuit when sending a message from a server directly to a connection when that connection is connected to the sending server, bypassing SQL Server entirely.

https://github.com/IntelliTect/IntelliTect.AspNetCore.SignalR.SqlServer/blob/master/src/IntelliTect.AspNetCore.SignalR.SqlServer/SqlServerHubLifetimeManager.cs#L167-L171

If you still want to do this, use DefaultHubLifetimeManager then for your in-memory hub, and SqlServerHubLifetimeManager for your one with groups.

[yp3y5akh0v]

Thanks, it's working as expected