We're evaluating NServiceBus, principally with MSMQ. We're keen to look towards scalability and reliability.
Theoretically speaking, if we were to have two compute units/Windows Services/etc., would the message be processed twice (potentially)?
We're trying to understand where the magic could happen, if it does. Is it in NServiceBus as the "application", or RabbitMQ as the "transport" over and above the basic MSMQ.
Or is this a daft question from someone who needs to know more?
Each "compute unit" (we call them endpoints, although it is possible to host multiple logical message processing endpoints within a single physical process boundary) would listen to only one queue. Any message added to a queue would only be processed by the endpoint listening to that queue.
That is, unless you're using Pub/Sub, in which case both endpoints could subscribe to the same event, but then each queue would get a copy of the message, and each endpoint (subscriber) would process it independently.
Or, it's possible using any of the centralized broker-based transports (Rabbit is one of them - basically anything except MSMQ) to have two endpoint instances working on the same server in a competing consumers pattern. In this case, as the name suggests, the processes will compete for messages.
In RabbitMQ, the first endpoint instance will Peek at the message, which will lock it out from other endpoint instances on the same queue, until the message is successfully received, or released for a retry. The SQL Transport and Azure transports work similarly.
NServiceBus isn't really an application. The metaphor of an Ethernet network applies pretty well: