NServiceBus Sql Server Transport only triggers on one instance

So our company decided to use NServiceBus today and I am facing a little issue here:

Our infrastructure consists of 4 webservers and one database which is accessed by each webserver. The goal is to send a message from one webserver and have each webserver handle it.
I am configuring my endpoint like so:

public static async Task<IEndpointInstance> CreateEndpoint()
    var endpointConfiguration = new EndpointConfiguration("ep");

    var transport = endpointConfiguration.UseTransport<SqlServerTransport>();

    var routing = transport.Routing();
    routing.RouteToEndpoint(typeof(DoSomething), "ep");

    return await Endpoint.Start(endpointConfiguration);

But when I am publishing an event using
await endpointInstance.Publish(command);
only one of the webservers handles the event. Usually its just the first one that catches the message from the database.

What config am I missing?


That is by design. An endpoint is a logical subscriber. Multiple physical subscribers are treated as one logical subscriber. Each logical subscriber gets a copy of the event.

If you need that behavior you are in the data distribution scenario which we don’t recommend to use messaging for.

That being said it is possible to make it work if you have valid reasons to go down that path, see https://docs.particular.net/samples/routing/data-distribution/

Would you mind explaining a bit your scenario why each webserver needs the message?
Another thing is that you mentioned send a message so essentially if one sender needs to tell all the webservers to do something you could make them uniquely addressable and directly send a command to those.


and then

for() {
   var options = new SendOptions();
   var message = new MyMessage();
   await endpoint.Send(message, options)


1 Like

Thanks for the responde Daniel.

The goal is to use NServiceBus to implement a SignalR-Core Backplane using SQL Server. Sadly our customers cannot provide needed infrastructure to use the already existing Backplane solutions from Microsoft.

Making them uniquely addressable seems like a valid solution for now since we are a bit under time pressure. I will try to implement a solution based on your response and if I have any further questions come back to this thread.


I would not advise the SQL transport to be used as the transport for the SignalR backplane due to the latency introduced by the SQL transport polling for messages mechanism.

Hi Marco

have you considered using Azure SignalR Service?

Or is the requirement to run fully on premise without anything in the cloud?

Have you seen our SignalR sample? https://docs.particular.net/samples/near-realtime-clients/ Maybe it is worth having a chat with the client again. Ultimately using the SignalR backplane is the right solution for what you are achieving and it seems counterproductive and risky to force you in doing this over NServiceBus. If things go wrong this might even backfire to you and your team. If you need help to find good arguments feel free to reach out to us over support at particular dot net