Database Reference
In-Depth Information
place order command to in the
orders.handler
MSMQ. In the Visual Stu-
dio 2012 debugger,
NServiceBus.Integration Nser-
viceBus.Master
is set in the command line to be used instead of
Config-
ure.Instance.RunDistributor()
.
The solution for the ordering will look like the following:
If there are too many place orders for
Orders.Handler
to receive, then a round-robin
effect will happen to the worker services across the
orders.handler.worker
MSMQ. The control queue is
orders.handler.distibutor.control
and the
data queue is
orders.handler.distibutor.storage
. The
DataInputQueue
,
or the data queue, is the queue where the client processes send their applicative messages.
ControlInputQueue
, or the control queue, is the queue where the worker nodes send
their control messages. The control queue is the distributor queue that the workers will
signal to the handler indicating that they are available to process the message. These
queues and worker processes could be spanned across machines or used on the same ma-
chine to distribute the load of the messages. If no workers are available for the handler to
distribute the messages, then the handler will process the message and respond back to the
sender. The workers are duplicated code for the handler and perform the same function;
their purpose is just to take the workload off the handler to distribute the load.
By default, there will be subscription storage information saved in the RavenDB database.
This information is for the worker processes to understand whom to respond back to when
responding. The master node is the handler, which receives messages from the sender cli-
ent. So, it knows that it has to respond to the sender client. However, the handler, which is
the master, sends the messages to the worker processes. So, the workers are only aware of
the handler. The handler will create subscription information so that the workers know
that they have to respond back to the sender client. This will be the subscription storage
