0

我们有一个 Silverlight 客户端，它在 Mac 上运行“浏览器外”。此客户端通过轮询双工绑定使用 WCF 服务。

在客户端中，我正在监听 System.ServiceModel.DuplexClientBase 派生的“InnerChannel”属性公开的“Faulted”事件，它代表客户端的服务。

恰好一分钟后，该“故障”事件被触发，之后通道不再工作，即当服务器尝试通过回调通道发送消息时，它会收到超时异常。

这是我的一个理论：我怀疑客户端中的底层轮询操作有 1 分钟的超时。在服务器端，pollingDuplexHttpBinding 部分的 serverPollTimeout 属性设置为超过一分钟。这意味着如果服务器在此期间没有任何信息可告诉客户端，则服务器会持有一个轮询请求超过一分钟。我怀疑这揭示了客户端轮询消息中的超时。为了测试我的理论，我将 serverPollTimeout 设置减少到不到一分钟，而且确实 - 没有显示问题。

在客户端，有PollingDuplexBindingElement.ClientPollTimeout属性，根据此博客，该属性正是应该告诉客户端等待一分钟以上的设置。此设置的默认值为 5 分钟，我什至明确设置了它——但问题仍然存在（没有上述解决方法）。

请注意，此问题仅在浏览器客户端之外的 Mac 上发生。

总结一下，这是我的问题：

  • 我如何/在哪里可以看到描述性错误消息，准确说明这里的问题是什么？
  • 为什么它只发生在浏览器客户端之外的 Mac 中？
  • 有人可以证实我的理论吗？
  • 如果我的理论是正确的——我如何才能真正为客户端中的轮询请求设置超时？
4

1 回答 1

0

在与 Microsoft 支持有关的长线程之后，这里是关于此问题的结论：

  • 该问题也与“常规” WCF 调用有关。如果我们从 SL Mac OOB 调用常规 WCF 操作，它将在恰好一分钟后超时，即使超时设置得更高
  • Microsoft 确认 60 秒是 Mac OS 上的默认超时，并且 SL 运行时不会调用所需的 Mac OS API 将其设置为更高的值，即使 SL 客户端代码使用记录在案的 SL API 来更改超时。他们说这是“设计使然”，因为他们不知道即使在长时间轮询中服务器可能需要这么长时间的任何情况
于 2012-08-06T10:58:59.300 回答