【问题标题】:Intermitent WCF service timeout exception间歇性 WCF 服务超时异常
【发布时间】:2012-10-18 09:58:03
【问题描述】:

我们有一个托管在 Windows 服务中的 WCF 服务和一个访问该服务的非线程客户端。该服务正在执行对 SQL Server 2008 数据库的数据访问。客户端偶尔会出现以下异常:

System.TimeoutException: The request channel timed out while waiting for a reply after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.

我知道这个错误对于 WCF 问题可能有点笼统,但我确信该错误不会发生,因为操作需要一分钟以上(我已经将超时时间增加了三倍,但它仍然会发生)。

该问题已发生在多个端点上,并且发生在对客户端代理的调用上。我将崩溃发生时服务到达的各个点记录到一个文本文件中,并看到服务的返回语句已到达。

客户端和服务已经以某种形式使用了两年多,而且这个问题似乎只是最近才出现,并且在对服务具有重要意义的领域没有任何明显的变化(尽管这两种说法在何时依赖都是危险的)调试问题)。

任何关于调查的建议、想法或建议将不胜感激。

这里是服务绑定:

<binding name="WSHttpBinding_IDataService" closeTimeout="00:01:00"
    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
    maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
    allowCookies="false">
  <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
      maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
  <reliableSession ordered="true" inactivityTimeout="00:10:00"
      enabled="false" />
  <security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
        realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="true"
        algorithmSuite="Default" establishSecurityContext="true" />
  </security>
</binding>

这是客户端绑定:

<binding name="WSHttpBinding_IAssessmentDataAccessContract"
         closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
         bypassProxyOnLocal="false" transactionFlow="false"
         hostNameComparisonMode="StrongWildcard"
         maxBufferPoolSize="2147483647"  maxReceivedMessageSize="2147483647"
         messageEncoding="Text" textEncoding="utf-8"
         useDefaultWebProxy="true" allowCookies="false">
    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
    <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
    <security mode="Message">
        <transport clientCredentialType="Windows" proxyCredentialType="None" realm="">
            <extendedProtectionPolicy policyEnforcement="Never"/>
        </transport>
        <message clientCredentialType="Windows" negotiateServiceCredential="true" 
                 algorithmSuite="Default" establishSecurityContext="true"/>
    </security> 
</binding>

【问题讨论】:

    标签: c# wcf


    【解决方案1】:

    我在连接到 Oracle 数据库的服务中遇到了类似的问题。我花了一些时间才找到罪魁祸首,但我要采取的第一步是在服务器和客户端上启用跟踪。 Here is the MSDN doc on how to do thatJump to the recomended settings for tracing in production environment

    听起来像是您在数据库中有一个 WCF 不知道如何序列化的值 TYPE,或者它不包含在您的 ServiceContract 的 KnownTypes 属性中。当我遇到这个问题时,它非常相似,但我需要挖掘跟踪以发现调用中的某些内容没有被正确序列化(或反序列化)。我的问题是在返回数据集而不是特定值时,很难准确找到罪魁祸首。

    如果您没有自定义错误处理程序,WCF 很容易锁定异常并且您的客户端会出现“超时”。

    【讨论】:

    • 我已经查看了这些痕迹,到目前为止还没有看到任何可以为我指明解决方案的方向。是什么表明您遇到了 KnownTypes 问题?
    • 实际上,我们必须在客户端和服务器上都设置调试。当我们发现似乎一方会发送但另一方从未收到任何东西时,我们打开了最大的追踪能力。经过一番大挖掘,我们发现最终发送无法序列化数据,并且会在我们代码之外的某个地方抛出异常。鉴于此,我们查看了对数据库的确切调用,以及返回的内容并使用特定数据类型(DBNull,愚蠢的吧?)重现了问题,然后我们将其添加到已知类型中。
    【解决方案2】:

    当崩溃发生时,看看是否到达了服务的返回语句。

    这有帮助,但并不意味着服务器端不会导致/添加问题。 您的方法是否可能返回非常大的有效负载,并且下载时间过长或超过了 WCF 绑定的最大大小?

    现在,您可能直到现在才看到此内容的原因是,您现在拥有 2 年的数据,因此您返回的内容可能比最初返回的要多。只是猜测。

    例如

    public string GetStuff()
    {
         return //large payload
    } 
    

    你在两端两端的绑定是什么样子的? maxStringContentLength 的值是多少?

    【讨论】:

    • 将服务和客户端绑定添加到问题中。
    • @AlanBradbury 消息有多大可能?在具有大量消息的非常慢的连接(
    • 实际上我可以在您的客户端配置中看到一个可能的错误。请参阅这部分 maxStringContentLength="8192" - 这应该与您的服务器端设置 2147483647 匹配 - 实际上该元素中的所有这些设置都应该匹配。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多