Question

Okay, so I’ve been trying to wrap my head around queue -> dead-letter queue -> poison subqueue of dead-letter queue -> ?

Now, as far as I understand, messages can be sent to the poison queue if they fail processing or if the Action on the message is not supported by the receiver. Most of the articles I’ve found show implementing the poison service with the same contract as the main service. Wouldn’t that put a message poisonous to the poison message queue into the poison message queue if the error is that the contract doesn’t support the message provided?

Wouldn’t it make more sense to have a handler that can handle anything in the poison queue? The below assumes a WCF Message, which probably isn’t safe either (and is completely untested), but is there a way to have fool-proof poison queue handling? The more I try to think through the edge cases with queueing, the more I feel that it’s impossible to have a complete system that handles all possibilities.

    [OperationContract(IsOneWay = true, Action = "*")]
    [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
    public void CatchAll(Message message)
    {
        // Log somewhere?
    }

Another thought is to have a trigger that moves all messages from the poison queue back into the dead-letter queue to be handled again – which will probably poison again and loop infinitely.

I guess the specific question is.. how do people handle poison messages in a dead-letter queue? And the general question is – how the heck do you handle all situations in MSMQ?

Answer 1

As far as I was aware, the MsmqMessage<T> type can be used in concert with any of the WCF msmq bindings.

So if you specify an recieve type of MsmqMessage<String> this should cover all bases. You will receive the message as a string. How you handle what is in the string is another story…