.net 为什么’；WCF支持服务端超时？

我们最近发现WCF不支持服务端（注意，服务端，而不是客户端）的超时操作。当客户端在指定的时间后断开连接时，我们的测试表明，对于netNamedPipeBinding、netTcpBinding和basicHttpBinding，我们指定的超时不会导致服务操作在被调用后停止。下面是我们尝试的特定绑定配置：

<bindings>
  <netNamedPipeBinding>
    <binding name="TestServiceBindingConfigurationNamedPipe"
             receiveTimeout="00:00:05"
             sendTimeout="00:00:05"
             closeTimeout="00:00:05"
             openTimeout="00:00:05" />
  </netNamedPipeBinding>
  <netTcpBinding>
    <binding name="TestServiceBindingConfigurationTcp"
             receiveTimeout="00:00:05"
             sendTimeout="00:00:05"
             closeTimeout="00:00:05"
             openTimeout="00:00:05" />
  </netTcpBinding>
  <basicHttpBinding>
    <binding name="TestServiceBindingConfigurationBasicHttp"
             receiveTimeout="00:00:05"
             sendTimeout="00:00:05"
             closeTimeout="00:00:05"
             openTimeout="00:00:05" />
  </basicHttpBinding>
</bindings>

使用netNamedPipeBinding和netTcpBinding，我们的客户端应用程序将在5秒后超时，但服务将无限期地继续运行

这就引出了我的问题——这是一个bug吗？如果服务运行时间超过预期，WCF是否有特定原因不想暂停服务？

在我看来，这方面的一些潜在负面问题包括：

服务实例的默认限制为10。因此，如果您的服务中存在永久运行的错误代码，并且被命中10次，那么您的服务将完全关闭；不接受新连接

由于缺少自定义日志记录或可能使用性能计数器，无法看到服务永远运行的事实

如果没有其他机制使操作超时，服务调用正在使用的任何资源都可能被无限期保留（例如，SQL行、页和表锁）

那么：

<system.web>
    <httpRuntime executionTimeout="inSeconds"/>
</system.web>

我自己也注意到了这个问题。。。我想不出一个好的理由来解释为什么他们不将服务端操作超时作为平台的一部分。

如果你有永远运行的坏代码，那么超时只会让事情变得更糟尽可能修复错误代码请参阅Eric Lippert关于此类情况的文章

---

如果正在开发中，您可能希望尝试在服务实现中设置一个调用

serviceCallThread.Abort（）

的

System.Threading.Timer

。但是，在返回之前，请确保已彻底解除计时器的警报-由于并发问题、不拥有服务调用到达的线程、

ThreadAbortException

的异常行为，这种方法非常容易出错，Eric解释了关于盲目终止在杂草中消失的代码的问题。

我们想要的是看到永远运行的坏代码。我们宁愿让它中止并抛出TimeoutException，也不愿让它在没有可见性的情况下潜在地占用CPU来告诉我们有坏代码要修复。是的，我的意思是去掉运行时间太长的代码是有意义的。但是当你不期望它永远运行时呢？当所有客户端都长时间断开连接时，您如何知道服务仍在执行以及它处于什么状态？关于使用计时器中止服务线程，这正是我们最终实现的。我问这个问题的部分原因是因为我真的很不愿意自己写这段代码，因为正如你所说，它“非常容易出错”。我一直希望我错过了某个配置行！

<system.web>
    <httpRuntime executionTimeout="inSeconds"/>
</system.web>