在 WCF 可靠请求回复服务方法中回复时如何处理失败

本文关键字：回复 何处理 失败 处理 WCF 请求 方法 服务 | 更新日期: 2023-09-27 18:36:07

在可靠的请求回复中，我了解回复是确认且可靠的。如果由于某种原因，回复消息在所有 8 次尝试中持续失败（默认重试次数为 8），则通道将出现故障。

在服务器端服务方法中，如果回复失败，我需要采取措施，但我看不到如何实现这一点，因为服务方法不知道 WCF 上下文。

    /// <summary>
    /// This is my service method, and does the reply in reliable request reply
    /// </summary>
    /// <returns></returns>
    public IModelJob GetNextJob()
    {
        //dequeue the next item if there is any
        var modelJob = _priorityQueue.Dequeue();
        //if all attempts to reply fail (or at least fail to be acknowledged) then when and how do I get a chance to requeue this job?
        return modelJob;
    }

当您是客户端并在代理本身上调用服务方法时，处理故障似乎要容易得多，因为您可以从 ClientBase 实现自己的代理。

我读过：http://msdn.microsoft.com/en-us/library/aa480191.aspx，并搜索了一下，但找不到任何具体的东西。

在 WCF 可靠请求回复服务方法中回复时如何处理失败

从

您最终支持的业务运营的角度来看待它。例如，如果服务需要以 30 分钟的固定间隔从客户端发送一系列消息，则您可能有一个要求（在业务意义上），即如果 120 分钟内看不到消息，则服务应通知管理员。这将在驱动服务的业务逻辑中实现。

当 WCF 未收到消息时，不能让它引发异常，这不是 WCF 的缺点 - 它怎么知道它首先应该期待一个消息？

请记住，可靠消息传递在应用程序下面的一层工作，就像 TCP 重传在您的 HTTP 应用程序完全不知道的情况下发生一样。在TCP级别需要重传或多次重传的事实不是接收者关心的问题，当然也不会在协议堆栈中抛出异常。由数据的发送者最终检测到无法发送数据，并对此采取措施。或者，在我给出的示例中，服务背后的业务逻辑在业务级别实现需求。

您可能对我写的一篇关于WS-ReliableMessaging的一些缺点的博客文章感兴趣。

相关文章：