WCF客户端在服务中断时挂起

Question

我有一个相当简单的WCF服务，为一堆智能客户端执行单向文件同步。 我注意到，当调用期间出现网络或服务中断时，客户端停止能够与服务器通信，直到整个应用程序重新启动。

该服务使用BasicHttpBinding运行，并使用IIS6（.svc页面）进行托管，使用transferMode =“Streamed”和messageEncoding =“Mtom”。 服务配置为使用默认InstanceContextMode（我认为是Per Call？）和ConcurrencyMode = Single。 它正在使用默认的限流行为，但我处于一个没有其他人访问的隔离测试环境中。

客户端是Windows服务。我使用ServiceProxyHelper来确保在Dispose()时正确地关闭Close()或Abort()连接，尽管没有会话，所以我认为这甚至并不重要。当出现错误时，客户端对象被处理，然后超出范围。在检测到异常之后，服务等待一段时间，然后创建一个新的客户端对象并再次尝试。因此，它应该从故障中恢复，但由于某种原因，所有后续对服务的调用都失败了。

我可以通过启动客户端，允许其传输几个文件，然后iisresetting服务器来可靠地复制此问题。首先，客户端通常显示“服务太忙”的错误（这映射到应用程序重新启动期间收到的IIS 503错误）。之后，所有后续对服务的调用都超时。据我所知，客户端甚至不会尝试进行调用。我已启用跟踪，所看到的是：超时错误，然后是“未能通过HTTP发送请求消息”警告，然后是另一个超时错误。

疯狂的是，当我在app.config中配置客户端使用Fiddler（端口8888）作为代理时，一切都按预期工作。所以不知何故，Fiddler作为代理关闭或完成了某种WCF本身无法完成的连接。您有什么想法吗？

注：已编辑服务属性：InstanceContextMode=Single和ConcurrencyMode=Multiple。没有任何区别。

- roufamatic

Answer 1

那真是太痛苦了。我花了很长时间才找到使用代理和不使用代理之间的区别，并开始查看<system.net>设置。结果发现，将此配置添加到客户端中可以解决问题：

  <system.net>
    <settings>
      <servicePointManager expect100Continue="false" />
    </settings>
  </system.net>

有人能解释一下发生了什么吗？为什么这个设置会导致WCF客户端在服务中断时无法修复地挂起？

- roufamatic

---

WebRequest 存在关于 100 Continue 功能的已知 bug。http://regis.decamps.info/blog/2010/12/c-bug-in-webrequest/ - rds

Answer 2

你确定这不是客户端问题吗？如果你的Windows服务在主线程之外的一个单独线程上进行WCF调用，并且在子线程中发生未处理的异常...调用线程可能会一直等待永远，因为它正在等待该线程返回。

这就解释了为什么服务内部出现异常，然后看起来服务不再调用服务...它挂起了。

在使用.NET 2.0 Windows服务中的计时器生成进程时曾经是一个巨大的问题。

- Justin Niessner

---

我认为这是客户端问题，但我不认为是线程问题，尽管您说得对，这些客户端是在与主线程分离的单独线程上生成的。我使用BackgroundWorker而不是线程，并已连接到RunWorkerCompleted事件以在线程出错时重新启动。我看到这个逻辑执行了，我也看到工作程序再次启动并尝试与服务通信。但是后续的调用失败了。 - roufamatic