对于带有MSMQ 3.0绑定的单向WCF服务：ServiceHost.Faulted事件处理的正确行为是什么？

Question

方案1 ：在发生故障的事件中，我正在重新启动服务，这意味着重新创建ServiceHost。

我已经实现了IErrorHandler来处理有毒消息，并且在将有毒消息移动到有毒队列之后，它调用RestartService方法。

现在，当消息中毒时，将首先调用Faulted事件，该事件将调用RestartService，但在成功成功打开ServiceHost之后不久，它将再次出现Faulted，但在这里，我已停止进一步重新启动它。

在这段时间内，在单独的线程上两次调用了IErrorHandler.HandleError，并且在两次调用IErrorHandler.HandleError的末尾（如果异常是MsmqPoisonMessageException的情况下）两次都无法找到将消息移至中毒队列的消息，而第二次将消息移至中毒队列的消息它将重新启动服务。

以下是被调用的方法序列：

ProcessMessage – message throws exception every time e.g. DB server is down
    ServiceHost.Faulted 
        RestartService
            ServiceHost.Faulted
                RestartService – skipped as still first call to RestartService not finished
    IErrorHandler.HandleError - Message not found to move to poison queue
        RestartService
    IErrorHandler.HandleError - Message moved to poison queue
        RestartService – skipped as a call to RestartService by first call to IErrorHandler.HandleError is not yet finished

方案2：在发生故障的事件中，我不重新启动服务。

以下是被调用的方法序列：

ProcessMessage – message throws exception every time e.g. DB server is down
    ServiceHost.Faulted
    IErrorHandler.HandleError - Message moved to poison queue
        RestartService 

现在，我担心的是，如果我遵循方案2，该方案更干净，性能更好，但是如果服务由于MsmqPoisonMessageException服务以外的其他原因而出现故障，则该服务将停止响应。

在这种情况下，您建议什么解决方案？

我在Windows XP和Windows Server 2003上使用MSMQ 3.0。

Answer 1

对于MSMQ 3，我们看到在FaultHandler中重新启动服务不是一个好主意，因为它可能导致消息重新处理，然后才能将消息移至中毒队列。

如果服务在处理有毒消息之前重新启动（这将会发生，因为它会发生故障->在引发poisonMessageException之前引发有故障的事件），则新服务主机可能会开始处理该消息，然后中毒处理无法找到中毒的消息。

我看到的问题是：如果WCF服务出现异常和故障怎么办？