WCF over MSMQ binding. How do I detect when a message is moved to the poison queue?

I am running a WCF client that invokes a WCF service via an MsmqBinding. Framework is .Net 4.0, client and server runs on Windows Server 2008 R2. The channel queue is transactional.

The service is hosted with these binding parameters: receiveErrorHandling="Move" receiveRetryCount="3" retryCycleDelay="00:00:20" maxRetryCycles="5"

Given that ((ReceiveRetryCount+1) * (MaxRetryCycles + 1)) is in effect, this will result in 4*6 = 24 retries of any given message before it is moved to the poison subqueue.

Attaching an IErrorHandler to my service I notice that HandleError is called with a MsmqPoisonMessageException a total of 6 times (for a poison message), before the wcf subsystem finally moves the message to the ;poison subqueue.

I want to log the precise time when a message is done being retried and the message is moved to the poison queue. It seems to me the only option is to count the number of times a certain message faults and compare this count with the binding MaxRetryCycles. This is awkward and errorprone.

My question is:

• Is there any way for me to conclusively d开发者_如何学Goetect the event where the wcf subsystem moves the message to the poison queue?

My references are: http://msdn.microsoft.com/en-us/library/aa395218.aspx

And: http://consultingblogs.emc.com/simonevans/archive/2007/09/17/A-comprehensive-guide-to-using-MsmqIntegrationBinding-with-MSMQ-3.0-in-WCF.aspx

The number of retries is of course an outcome of your parameters; however in your IErrorHandler you can explicitly move the message to the poison queue yourself. Otherwise, it will always move based on your binding parameters, and would be detected by listening to the poison queue like any other queue.

There are a number of good monitoring solutions that you can use to watch message queues for the arrival of a message. MonitorWang is an open source one that can detect when a message has arrived in a poison message or error queue. Detecting when a message has been received in the error queue is more reliable than trying to detect when a message has been sent to the error queue.