FAQ Contents

• MsmqTransportConfig
• Defining a message
• Store & forward for a message
• Discarding old messages
• Instantiating a message
• Send a message
• Set message destination
• Messages and queues
• Handling messages
• Message handler ordering
• Referencing IBus in a handler
• Technical message information
• Replying to messages
• Handling responses
• Publish Subscribe
• Exception handling
• Exposing web/wcf services
• Type not registered in serializer
• Insufficient resources to perform operation
• How to specify your input queue name
• What happens when a worker goes down?
• RunMeFirst.bat throws an exception

How do I handle exceptions?

Don't.

NServiceBus has exception catching and handling logic of its own which surrounds all calls to user code. When an exception bubbles through to the NServiceBus infrastructure, it rolls back the transaction on a transactional endpoint, causing the message to be returned to the queue, and any messages that user code tried to send or publish to be undone as well.

At that point, NServiceBus will retry to handle that message a configurable number of times (default of 5) and if the message fails on every one of those retries, the message will then be moved to the configured error queue.

Administrators should monitor that error queue so that they can see when problems occur. The message in the error queue contains the source queue and machine so that the administrator can go see what's wrong with that node and possibly correct the problem (like bringing up a database that went down).

Once the administrator corrects the problem, they can use the ReturnToSourceQueue.exe tool to send the relevant message back to its original queue so that it can be processed again - this time successfully.

For more information on this process, click here.