WCF响应消息需要40分钟，不会引发超时异常

我在IIS7中托管了一个WCF服务（服务和客户端配置在本文末尾）。我遇到了一个奇怪的场景，我希望有人能对如何攻击它并找到解决方案有一些想法

该服务仅公开一个协定“ProcessMessage”。我可以使用该契约从服务发送/接收同步消息，性能良好，但对该契约的一个特定调用返回的数据超过65KB；大约1MB。最初调用它时，我收到了预期的最大接收大小超出错误。所以我增加了maxReceivedMessageSize，现在这个特殊的调用需要40分钟才能返回到客户端。这远远超出了任何超时设置，也远远超出了我的预期。服务器端处理时间仅为2秒。它似乎在客户端被搁置

我也尝试过在文件中增加一些其他配额，但没有效果

任何想法都将不胜感激。谢谢

服务配置：

  <system.serviceModel>
<services>
  <service behaviorConfiguration="Lrs.Esf.Facade.Startup.FacadeBehavior"
    name="Lrs.Esf.Facade.Startup.FacadeService">
    <endpoint address="" binding="wsHttpBinding" bindingConfiguration="default" contract="Lrs.Esf.Facade.Startup.IFacadeService">
      <identity>
        <servicePrincipalName value="lrsdomain/PensionDev" />
      </identity>
    </endpoint>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
  </service>
</services>
<bindings>
  <wsHttpBinding>
    <binding name="default">
      <security mode="None"/>
    </binding>
  </wsHttpBinding>
</bindings>
<behaviors>
  <serviceBehaviors>
    <behavior name="Lrs.Esf.Facade.Startup.FacadeBehavior">
      <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
      <serviceMetadata httpGetEnabled="true" />
      <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
      <serviceDebug includeExceptionDetailInFaults="true" />

    </behavior>
  </serviceBehaviors>
</behaviors>

  <system.serviceModel>
<bindings>
  <wsHttpBinding>
    <binding name="WSHttpBinding_IFacadeService" closeTimeout="00:01:00"
        openTimeout="00:01:00" receiveTimeout="00:1:00" sendTimeout="00:01:00"
        bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
        maxBufferPoolSize="52428800" maxReceivedMessageSize="6553600"
        messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
        allowCookies="false">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
          maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
      <security mode="None">          
      </security>
    </binding>
  </wsHttpBinding>
</bindings>
<client>
  <endpoint address="http://esf2.facade.testpe.pg.local/FacadeWcf/FacadeService.svc"
      binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IFacadeService"
      contract="FacadeServiceReference.IFacadeService" name="WSHttpBinding_IFacadeService">
    <identity>
      <servicePrincipalName value="lrsdomain/PensionDev" />
    </identity>
  </endpoint>
</client>

客户端配置：

  <system.serviceModel>
<services>
  <service behaviorConfiguration="Lrs.Esf.Facade.Startup.FacadeBehavior"
    name="Lrs.Esf.Facade.Startup.FacadeService">
    <endpoint address="" binding="wsHttpBinding" bindingConfiguration="default" contract="Lrs.Esf.Facade.Startup.IFacadeService">
      <identity>
        <servicePrincipalName value="lrsdomain/PensionDev" />
      </identity>
    </endpoint>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
  </service>
</services>
<bindings>
  <wsHttpBinding>
    <binding name="default">
      <security mode="None"/>
    </binding>
  </wsHttpBinding>
</bindings>
<behaviors>
  <serviceBehaviors>
    <behavior name="Lrs.Esf.Facade.Startup.FacadeBehavior">
      <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
      <serviceMetadata httpGetEnabled="true" />
      <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
      <serviceDebug includeExceptionDetailInFaults="true" />

    </behavior>
  </serviceBehaviors>
</behaviors>

  <system.serviceModel>
<bindings>
  <wsHttpBinding>
    <binding name="WSHttpBinding_IFacadeService" closeTimeout="00:01:00"
        openTimeout="00:01:00" receiveTimeout="00:1:00" sendTimeout="00:01:00"
        bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
        maxBufferPoolSize="52428800" maxReceivedMessageSize="6553600"
        messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
        allowCookies="false">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
          maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
      <security mode="None">          
      </security>
    </binding>
  </wsHttpBinding>
</bindings>
<client>
  <endpoint address="http://esf2.facade.testpe.pg.local/FacadeWcf/FacadeService.svc"
      binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IFacadeService"
      contract="FacadeServiceReference.IFacadeService" name="WSHttpBinding_IFacadeService">
    <identity>
      <servicePrincipalName value="lrsdomain/PensionDev" />
    </identity>
  </endpoint>
</client>

---

您似乎没有增加服务器端各种参数的大小，您应该尝试一下！在服务器端使用客户机配置文件中的绑定配置-服务可能会阻塞，因为它仍然默认为64K消息大小

此外，客户端绑定中的

receiveTimeout

有点滑稽-它缺少一个零位：

<binding name="WSHttpBinding_IFacadeService" 
receiveTimeout="00:1:00" 

---

您似乎没有在服务器端增加各种参数的大小-您应该尝试一下！在服务器端使用客户机配置文件中的绑定配置-服务可能会阻塞，因为它仍然默认为64K消息大小

此外，客户端绑定中的
receiveTimeout
有点滑稽-它缺少一个零位：

<binding name="WSHttpBinding_IFacadeService" 
receiveTimeout="00:1:00" 

我已经找出了问题的基本原因和解决方法，不过，如果能提供更多的见解，那就太好了

WCF正在以XML格式序列化数据集。我强制将数据集序列化为字节[]，时间缩短为4秒。一种猜测是，对4MB XML中的所有字符进行转义以使HTTP通信有效是导致问题的原因
 我已经找到了问题的基本原因和解决方法，不过，如果能有更多的见解就更好了

WCF正在以XML格式序列化数据集。我强制将数据集序列化为字节[]，时间缩短为4秒。一种猜测是，对4MB XML中的所有字符进行转义以使HTTP通信有效是导致问题的原因
 谢谢你，马克。我不认为这些设置适用于服务器端，但我在你的建议后尝试了，结果没有改变。我还修复了超时。由于我在客户端收到了关于消息大小的原始错误，我的假设是故障发生在那里，而不是服务器上。超时没有被绊倒这一事实相当令人困惑。这几乎就像WCF在客户端完成了消息的处理，并认为它将控制权交还给了客户端，但由于某种原因仍然处于阻塞状态。好吧，很有趣-您真的没有在客户端收到任何超时或其他错误吗？这很奇怪……您在服务器的事件日志中看到任何条目了吗？也许我在日志里放了些什么？看起来很奇怪，什么都没有……只是为了见鬼——你能编写你自己的服务主机（一个控制台应用程序，它实例化一个服务主机并调用.Open（）和它）并看看这是否有效吗？您还需要为服务器上的端点指定一个基址或显式地址（在这种情况下），完全没有超时。在杀死它之前，我让它运行了15分钟左右。日志中也没有错误。主机应用听起来是个不错的尝试。我要试一试。谢谢你的想法，马克，谢谢。我不认为这些设置适用于服务器端，但我在你的建议后尝试了，结果没有改变。我还修复了超时。由于我在客户端收到了关于消息大小的原始错误，我的假设是故障发生在那里，而不是服务器上。超时没有被绊倒这一事实相当令人困惑。这几乎就像WCF在客户端完成了消息的处理，并认为它将控制权交还给了客户端，但由于某种原因仍然处于阻塞状态。好吧，很有趣-您真的没有在客户端收到任何超时或其他错误吗？这很奇怪……您在服务器的事件日志中看到任何条目了吗？也许我在日志里放了些什么？看起来很奇怪，什么都没有……只是为了见鬼——你能编写你自己的服务主机（一个控制台应用程序，它实例化一个服务主机并调用.Open（）和它）并看看这是否有效吗？您还需要为服务器上的端点指定一个基址或显式地址（在这种情况下），完全没有超时。在杀死它之前，我让它运行了15分钟左右。日志中也没有错误。主机应用听起来是个不错的尝试。我要试一试。谢谢你的想法，Marc。我已经运行了Fiddler和客户流程的完整跟踪，并获得了更多信息。响应消息在几秒钟后返回到客户端计算机（fiddler），但消息日志跟踪和“通过通道接收到消息”直到40分钟后才被记录。我猜反序列化消息需要40分钟。我将服务主机从IIS中取出，并创建了一个TCP端点