NServiceBus Router and failed/poison messages

I’m looking at the atomic update-and-publish example, and wonder how failed/poison messages should be handled?

The related docs page says that failed messages are moved to the ‘poison’ message queue - is this the equivalent of the ‘error’ queue configured on a standard endpoint? Or is it somehow different? And should ServiceControl be set up to monitor this queue?

When the router is configured to create its own queues and both interfaces are SQL databass, it creates a poison queue in both interfaces’ databases (i.e. the web/business database and the transport database) - can/should ServiceControl be set up to monitor both these queues?

Hi @bdlane,

The poison queue used by NServiceBus.Router is a separate queue from the error queue that’s configured in your endpoints (and monitored by ServiceControl). Messages that end up in the NServiceBus.Router poison queue failed due to:

  • serialization errors
  • messages that failed to be routed to the correct endpoint.

This queue is not actively monitored by ServiceControl. You could try to configure NServiceBus.Router’s poison queue, to point to the same error queue as is configured in your endpoints (now the default is set to ‘poison’ which creates a dedicated queue). The messages should contain all the headers required for ServiceControl to process and retry those messages as well.

Kind regards,
Laila

Thanks @laila.bougria for clearing that up - make sense.

Is the term ‘poison’ vs ‘error’ an important distinction here then? Just wondering why it differs from the main NServiceBus terminology.

I tried pointing a ServiceControl instance at the poison queue and it picked up the messages fine, so that seems to work - at least for the failures I tried.

In the sample, the router creates a poison queue on both interfaces. On the ‘main’ transport side, it would be easy to just configure the router to use the standard error queue and have the ServiceControl instance for the main transport pick up and handle the failed messages. But the poison queue on the web side isn’t reachable by the main ServiceControl instance - because this is a ‘non standard’ physical routing configuration, right?

So the options to monitor the poison queue on the web side would be:

Are there any other options I’ve missed?