WCF 跟踪.如何获得关闭连接的确切原因? [英] WCF Tracing. How I can get the exact reason for closing connection?

问题描述

在我的 WCF 服务中，尝试传输大数据时，我经常收到错误消息:底层连接已关闭:连接已意外关闭

In my WCF service, when trying transfer large data I constantly get an error: The underlying connection was closed: The connection was closed unexpectedly

我想知道是什么特殊原因引发了这个错误，所以我设置了 WCF Tracing 并且可以读取 traces.svclog 文件.

I want to know what particular reason invokes this error, so I set up WCF Tracing and can read traces.svclog file.

问题是，我可以在这个文件中看到很多关于流程的信息，我可以看到出现异常的确切时间，但我看不到确切的原因.是由于 MaxReceivedMessageSize 还是类似的原因.

The problem is, that I can see in this file a lot of information about flow of processes, I can see exact time when exception is appeared, but I can't see the exact reason for that. Is it due to MaxReceivedMessageSize or something like that.

是 traces.svclog 不能包含此类信息还是我做错了什么?

Is it so that traces.svclog can not contain such information or am I doing something wrong?

如何获得这些信息?

已编辑(添加):

来自我的服务器端 app.config:

From my server-side app.config:

    <system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="NAVBinding_ICustomer_Service"
                closeTimeout="01:50:00"
                openTimeout="01:50:00" receiveTimeout="01:50:00" sendTimeout="01:50:00"
                allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
                maxReceivedMessageSize="2147483647" messageEncoding="Text"
                textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
                <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
                    maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                <security mode="None">
                    <transport clientCredentialType="None" proxyCredentialType="None"
                        realm="" />
                    <message clientCredentialType="UserName" algorithmSuite="Default" />
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <services>
        <service name = "Customer_Service"  behaviorConfiguration="returnFaults">
            <endpoint name="NAVBinding_ICustomer_Service"
               address  = "http://localhost:8000/nav/customer"
               binding  = "basicHttpBinding"
               bindingConfiguration= "NAVBinding_ICustomer_Service"
               contract = "NAVServiceReference.ICustomer_Service"/>
        </service>
    </services>
    <behaviors>
        <serviceBehaviors>
            <behavior name="returnFaults" >
                <serviceDebug includeExceptionDetailInFaults="true" />
                <serviceMetadata httpGetEnabled="true" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
 </system.serviceModel>

已编辑(添加):

将 WCF 服务从黑匣子"转变为易于排除故障的服务的正确和最佳方法是什么?您使用哪些工具和技术对 WCF 服务进行故障排除?

What is the right and best way to turn WCF service from a "black box" to an easily troubleshooted service, which tells the reason why something goes not the expected way? What tools, techniques you use to troubleshoot WCF service?

推荐答案

忽略maxRequestLength的问题(其他人已经回答)，我将尝试回答您关于如何对 WCF 进行故障排除的原始问题.

Ignoring the problems with the maxRequestLength (which have been answered by others), I will have a go at answering your original question about how to troubleshoot WCF.

如果您已经在使用服务跟踪查看器(我无法从问题中看出如果您只是手动查看它们) - 可能所有细节都不是进入文件.

If you are already using the Service Trace Viewer (I couldn't tell from the question if you were just viewing them by hand) - it is possible that all the details aren't going into the file.

当我想获得真正的硬核时，我会启用所有日志记录参数消息记录.(这会生成一些大的服务日志，所以不要离开它打开)

When I want to get really hardcore, I enable all the logging parameters for message logging. (This will generate some big service logs though so don't leave it on)

 <system.serviceModel>
  <diagnostics>
   <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="-1" />
  </diagnostics>
 </system.serviceModel>

如果您不使用 Microsoft 服务跟踪查看器，我建议您这样做.它提供我需要的所有信息来追踪那些棘手的消息握手，消息大小异常等.这是 MSDN 参考，可帮助您入门http://msdn.microsoft.com/en-us/library/aa751795.aspx

If you are not using the Microsoft Service Trace Viewer I recommend that. It gives all the information I need to track down those tricky message handshake, message size exceptions etc. Here is an MSDN reference to get you started http://msdn.microsoft.com/en-us/library/aa751795.aspx

存在潜在问题的跟踪交互在左上角的详细窗格通常会突出显示异常红色的服务事件.有时你会遇到多个问题作为内在错误通过服务堆栈级联 - 但您可以在跟踪查看器.

Trace interactions that have potential problems are hilighted in yellow on the left, and the detailed pane on the top right will normally hilight the exceptional service event in red. Sometimes you will get multiple problems as the inner error cascades through the service stack - but you can see it all in the trace viewer.

如果您在服务器的服务日志"中一无所获，那么您的异常可能完全在客户端 - 理论上您可能会超出某些客户端在任何消息实际到达之前的侧安全参数(消息大小等)Web 服务端 - 但客户端问题通常更容易追踪，因为您知道您只需要担心在客户端编辑配置文件(即不是因为客户端和服务器设置之间的任何交互).

If you get nothing in your server 'service log', then it is possible your exceptions are entirely at the client end - theoretically you could exceed some of the client side security parameters (message size etc) before any message has actually reached the web service end - but client problems are generally easier to track down because you know you only have to worry about editing the config file at the client end (i.e. it's not because of any interaction between the client and server settings).

这篇关于WCF 跟踪.如何获得关闭连接的确切原因?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！