1
votes

When setting up NServiceBus with MSMQ using the standard IServer config options, you define:

  • an input queue
  • an error queue.

When your NServiceBus Message Handler fails handling the message for whatever reason, it throws an exception and moves the message to the error queue.

Is the message in the error queue the exact same message that was in the input queue? If so, which I imagine it is, is there any way to know why those messages failed? Is there any metadata attached to them that might contain the original exception that was thrown?

Being able to do this would be especially useful in scenarios when your Handler is set to retry a number of times greater than one. This is because even if fatal errors might be thrown in the Handler, and logged, they're not really Fatal as such until they go in the error queue, because that's when they've actually failed.

Any ideas?

cheers

1

1 Answers

2
votes

It's an exact copy of the message that is send to the error q. The message id and source queue is stored in the headers to enable the message to be replayed. In 2.5 there is no good way to get the exception details for the failed message so you have to correlate the message id with entries the logfiles. The fact that NSB reties for you will often cause the same logmessage to be displayed multiple times for a message so make sure to use the last entry.

This is of course not very user friendly and has been fixed in the upcoming 3.0 where you can register Failure managers that let's you hook into NSB to get this info. The default Failure Manager will put the exception details in a headers so that you can easy get at them by looking at the failed message.