3

在可靠的请求回复中，我了解回复是公认且可靠的。如果由于某种原因，回复消息在所有 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并进行了搜索，但找不到任何具体内容。

4

1 回答 1

0

根据您最终支持的业务运营来考虑它。例如，如果服务期望每隔 30 分钟定期从客户端发送一系列消息，那么您可能有一个要求（在业务意义上），如果一条消息在 120 分钟内没有看到，那么服务应该通知行政人员。这将在驱动您的服务的业务逻辑中实现。

当它没有收到消息时，你不能让它抛出异常，这不是 WCF 的缺点——它怎么知道它应该首先期待一个异常？

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

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

于 2013-11-24T03:12:29.230 回答