NServiceBus offers four levels of consistency guarantees with regards to message processing, depending on the selected transport. The default consistency level is TransactionScope (Distributed Transaction), but a different level can be specified using code configuration API.
See the Transports Transactions article to learn more about NServiceBus consistency guarantees.
The default TransactionScope timeout limit is 1 minute. This limit can be adjusted up to the machine-wide maximum timeout value. The machine-wide maximum is 10 minutes by default, but it can be adjusted if needed.
Distributed Transaction Coordinator
In Windows, the Distributed Transaction Coordinator (DTC) is an OS-level service which manages transactions that span multiple resources, e.g. queues and databases.
The easiest way to configure DTC for NServiceBus is to follow the installation guide, or to use the dedicated PowerShell commandlets.
Troubleshooting Distributed Transaction Coordinator
The DTCPing tool is useful for verifying that the DTC service is configured correctly, as well as for troubleshooting:
For more information, refer to the Troubleshooting MSDTC issues with the DTCPing tool article on MSDN.
If the DTCPing WARNING: The CID Values for Both Test Machines Are the Same message appears when running the DTCPing tool, check to see if the machine name is longer than 14 characters. For DTCPing and MSDTC to work, the machine name should be 14 characters or shorter.
Message processing loop
Messages are processed in NServiceBus in the following steps:
- The queue is peeked to see if there is a message.
- If there's a message then a transaction is started.
- The queue is contacted again to receive a message, multiple threads may have peeked the same message. The queue makes sure only one thread actually gets a given message.
- If the thread is able to get it, NServiceBus tries to deserialize the message. If it fails, the message moves to the configured error queue and the transaction commits.
- After a successful deserialization, NServiceBus invokes all infrastructure, message mutators, and handlers. An exception in this step causes the transaction to roll back and the message to return to the input queue. The message will be re-sent for a configured number of times; if all attempts fail then it will be moved to the error queue.
Refer to the Message Handling Pipeline article to learn more about message processing.
Refer to the Recoverability and the ServicePulse: Failed Message Monitoring articles to learn more about error handling, automatic and manual retries, as well as processing failures monitoring.
Limitations
When enabling MSDTC on Amazon RDS for SQL Server, a set of limitations must be taken into account.