views:

232

answers:

1

I learned how to use an NServiceBus Distributor process on the FullDuplex sample from the article Getting the NServiceBus Distributor Working and it made me wonder:

In order to use the distributor, I need the following queues:

  • MyClientInputQueue - the input queue for the single client
  • distributordatabus - the distributor's queue to send messages to
  • distributorcontrolbus - what the distributor uses to store its state
  • server1messagebus - the input queue for the first server instance
  • server2messagebus - the input queue for the second server instance

This means that in order to scale with the distributor, every time I want to scale out with another server, I need to have an independent config file which specifies a new server message bus queue. If I want to scale back down, I have vestigial config files and queues left over.

This seems unnecessary since, during my testing without the distributor, I noticed that if I spun up another instance of a server (just by selecting Debug-Start New Instance in Visual Studio while debugging) then the new program instance (which is the same binary and has the same config file and same input queue) seems to load balance fairly well with the first instance. The requests seem to go back and forth between servers when issued by the client.

If this load balancing is effective, it means I could scale out simply by adding duplicate instances pointing to the same highly available input queue, without requiring any additional resource allocation. That would be much easier!

So what, then, are the advantages of the Distributor?

My only guess comes from the Distributor documentation which states that the distributor is "designed never to overwhelm any of the worker nodes configured to receive work from it." Can't I just control how much work a worker process can chew through using the NumberOfWorkerThreads property of the MsmqTransportConfig on each worker?

+1  A: 

Since a distributor is used primarily to scale out the processing of a single message type, and following the recommendations of having similarly isolated the processing of that message type, we can name many of the queues the same as the message type: so instead of 'distributordatabus', 'server1messagebus', and 'server2messagebus', all of them would be named the same, but each would be on a different machine. Then we'd name the distributor's control bus similar to the message type, but just with a '_control' suffix (or something like that).

So what, then, are the advantages of the Distributor?

It's for scaling out to many machines - which can't share an input queue.

Udi Dahan