How can I explicitly mark messages as poisoned in a transactional MSMQ with WCF

Question

I'm using MSMQ version 4 and have a transactional queue. I'm using WCF to listen to the queue for incoming messages.

While processing there is a dependency on third party components that might fail or be unavailable for a longer period of time. To compensate for this I use the poison message handling functionality in MSMQ 4 (http://msdn.microsoft.com/en-us/library/aa395218.aspx) to retry messages x amount of times with y amount of wait time.

However in certain situations I know the input message is invalid/poisoned. When this occurs throwing exceptions would make the message follow the poison message handling routine as all other messages with all the retries and wait times. But when I know the message is poisoned I don't see a reason to retry and wait the configured time for it to be handled by the poison queue.

Is there any way to explicitly mark a message as poisoned so it won't follow the configured retry flow and moves to the poison queue immediately?

Subterrane

I have exactly the same problem., I take it you found no solution? – Vaudevillian

@Vaudevillian Indeed, no solution found yet. – Subterrane

I am a MSMQ newbie and I haven't tried this - sorry if it is silly. This was in the article you linked to, "The poison queue is a sub-queue of the main queue, is named "poison" and is automatically generated by MSMQ. To access it, provide the main queue name followed by a ";" and the sub-queue name, in this case -"poison". Couldn't you detect the poison messages, remove them from the main queue and manually send them to the built in poison queue? – Fad

Answer 1

Well I will suggest in such case store request data in the DB and do not throw any exception so for WCF message is processed successfully and will be removed from queue.

This data we can processed later if required, it is easy to process data from DB than monitor/manage poison queue.

You can have some configuration based on that you can decide next processing timestamp of the message and a thread can re-process such messages from DB.

Tessie