Historically MSMQ is the first transport supported by NServiceBus. In version 5 it still is by far the most commonly used one. Because of these and also the fact that MSMQ client libraries are included in .NET Base Class Library (
System.Messaging assembly), MSMQ transport is built into the core of NServiceBus.
Because of the way MSMQ API has been designed i.e. polling receive that throws an exception when timeout is reached the receive algorithm is more complex than for other polling-driven transports (such as SQLServer).
The main loops starts by subscribing to
PeekCompleted event and calling the
BeginPeek method. When a message arrives the event is raised by the MSMQ client API. The handler for this event starts a new receiving task and waits till this new task has completed its
Receive call. After that is calls
BeginPeek again to wait for more messages.
Because of historic reasons, the configuration for MSMQ transport has been coupled to general bus configuration in the previous versions of NServiceBus.
Following settings are purely related to the MSMQ:
From version 4 onwards these settings are configured via a transport connection string (named
nservicebus/transport for all transports). Before V4 some of these properties could be set via
MsmqMessageQueueConfig configuration section while other (namely the connectionCache and the ability to use non-transactional queues) were not available prior to V4.
<configuration> <configSections> <section name="MsmqMessageQueueConfig" type="NServiceBus.Config.MsmqMessageQueueConfig, NServiceBus.Core" /> </configSections> <MsmqMessageQueueConfig UseDeadLetterQueue="true" UseJournalQueue="false" /> </configuration>
<connectionStrings> <add name="NServiceBus/Transport" connectionString="cacheSendConnection=true;journal=false;deadLetter=true;useTransactionalQueues=true"/> </connectionStrings>
NServiceBus is designed in such a way that a user does not have to care about exception handling. All the heavy lifting is done by the framework via a two-level retries mechanism.
From V4 onwards the configuration for this mechanism is implemented in the
<configuration> <configSections> <section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig , NServiceBus.Core" /> </configSections> <MsmqTransportConfig ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5"/> </configuration>
<configuration> <configSections> <section name="MessageForwardingInCaseOfFaultConfig" type="NServiceBus.Config.MessageForwardingInCaseOfFaultConfig, NServiceBus.Core" /> <section name="TransportConfig" type="NServiceBus.Config.TransportConfig, NServiceBus.Core"/> </configSections> <MessageForwardingInCaseOfFaultConfig ErrorQueue="error"/> <TransportConfig MaximumConcurrencyLevel="5" MaxRetries="2" MaximumMessageThroughputPerSecond="0"/> </configuration>
In V3 some of these setting were available via
MsqmTransportConfig section with following
ErrorQueue(the queue where messages that fail a configured number of times) settings can be set both via the new
MessageForwardingInCaseOfFaultConfigsection and the old
MaxRetriesas well as the throttling (
NumberOfWorkerThreads) settings can be set only via
Last modified 2015-05-27 20:52:23Z