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

问题描述

在我的WCF服务中，当尝试传输大数据时，我会不断收到错误： 底层连接已关闭：连接意外关闭
$ b

我想知道什么特别的原因调用这个错误，所以我设置了 WCF跟踪并且可以读取 traces.svclog 文件。 p>

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

是否因为 traces.svclog 不能包含此类信息或者我做错了什么？

如何获取这些信息？

已编辑（已添加）： / p>

从我的服务器端app.config：

 < system .serviceModel> 
< bindings> 
< basicHttpBinding> 
< binding name =NAVBinding_ICustomer_Service
 closeTimeout =01:50:00
 openTimeout =01:50:00receiveTimeout =01:50:00sendTimeout = 01:50:00
 allowCookies =falsebypassProxyOnLocal =falsehostNameComparisonMode =StrongWildcard
 maxBufferSize =2147483647maxBufferPoolSize =2147483647
 maxReceivedMessageSize =2147483647messageEncoding = Text
 textEncoding =utf-8transferMode =BuffereduseDefaultWebProxy =true> 
< readerQuotas maxDepth =2147483647maxStringContentLength =2147483647
 maxArrayLength =2147483647maxBytesPerRead =2147483647maxNameTableCharCount =2147483647/> 
< security mode =None> 
< transport clientCredentialType =NoneproxyCredentialType =None
 realm =/> 
< message clientCredentialType =UserNamealgorithmSuite =Default/> 
< / security> 
< / binding> 
< / basicHttpBinding> 
< / bindings> 
< services> 
< service name =Customer_ServicebehaviorConfiguration =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服务问题的工具，技巧

解决方案

忽略maxRequestLength的问题

如果您已经在使用服务跟踪查看器我不能从问题
，如果你只是手观察他们） - 这可能是所有的细节不是
进入文件。

当我想得到真正的核心，我启用所有的记录参数
消息日志记录。 （这将产生一些大的服务日志，所以不要留下
it）

 < system.serviceModel> ; 
< diagnostics> 
< messageLogging logEntireMessage =truelogMalformedMessages =truelogMessagesAtServiceLevel =truelogMessagesAtTransportLevel =truemaxMessagesToLog = -  1/> 
< / diagnostics> 
< /system.serviceModel> 
  

如果您不使用Microsoft服务跟踪查看器，我建议。它
提供了我需要跟踪这些棘手的消息握手，消息
大小异常等的所有信息。这是一个MSDN引用让你开始
http://msdn.microsoft.com/en-us/library/aa751795.aspx

具有潜在问题的跟踪交互在左侧的
上以黄色显示，右上角的详细窗格通常将显示红色的异常
服务事件。有时你会得到多个问题，因为内部
错误通过服务堆栈级联 - 但你可以看到它在
跟踪查看器。

如果您得到没有什么在你的服务器'服务日志'，那么可能你的异常完全在客户端 - 理论上，你可以超过一些客户端
端安全参数（消息大小等）之前任何消息实际达到
web服务结束 - 但是客户端问题通常更容易跟踪，因为你知道你只需要担心在客户端编辑配置文件（即它不是因为客户端和服务器设置之间的任何交互）。

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

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

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.

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

How such information could be obtained?

Edited (added):

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>

Edited (added):

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?

解决方案

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>

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.

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屋！