Poison message should not be send to the error queue

[ramonsmits]

When messages fail header deserialization the transport forward these messages to the error queue. Problem is that SC cannot do anything with these messages as there is no FailedQ header. The bad thing here is that customers do not have a way to 'retry' such messages as we don't know from which queue the messages was forwarded.

Such poison messages are probably best moved to a Poison (sub)queue specific to the endpoint.

For example, the following issue caused a massive amount of messages to fail and it was a huge problem to solve and required manual inspection and heuristics to move the messages back to the correct queues:

• Dynatrace causes header corruption which results in failed  #125

[ramonsmits]

Solutions:

• Foward to endpoint specific "poison" queue (endpointname + .poison)
• Move to "poison" subqueue as WCF does via native MQMoveMessage API.
• Base64 encoding "extension" put the base64 string in a new header collection so that we can add the "FailedQ" header and serializer it so that it can safely be send to the error queue.
• Reject the message via native MQMarkMessageRejected API so that it is put in the TDLQ of the sender.

[dvdstelt]

+1000.

We just had a call with a customer that paid a couple of thousand for critical support, paid Microsoft for support and possible Dynatrace for support. The error was "failed to import because it's missing NServiceBus.FailedQ header", but the problem was what Ramon described above.
2020 isn't the year this was registered, it was the year I joined this company! ;-)

• Poison messages are moved to Error Queue ServiceControl#853