views:

240

answers:

1

Hello,

I'm running a WCF service hosted by a windows service (calling from a asp.net site).

When I get a timeout (because the sendTimeout attribute has been exceeded) while calling through a "BasicHttp" endpoint, I get expected error message:

"The request channel timed out while waiting for a reply after 00:01:00. ...."

but when calling through a NetTcp endpoint (with Transport security) I get the more general error:

"The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state."

Does anybody know why that is? Am I missing something in the configuration?

My client-side configuration is:

    <netTcpBinding>
            <binding name="netTcpBindingConfig" closeTimeout="00:01:00"
             openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:00:10"
             transactionFlow="false" transferMode="Buffered" transactionProtocol="OleTransactions"
             hostNameComparisonMode="StrongWildcard" listenBacklog="10"
             maxBufferPoolSize="524288" maxBufferSize="655360" maxConnections="10"
             maxReceivedMessageSize="65536000">
                <readerQuotas maxDepth="32" maxStringContentLength="65536000" maxArrayLength="16384"
                    maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                <reliableSession ordered="true" inactivityTimeout="00:10:00"
                    enabled="false" />
                <security mode="Transport">
                    <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
                    <message clientCredentialType="Windows"  />
                </security>
            </binding>
        </netTcpBinding>


        <basicHttpBinding>

            <binding name="basicHttpBindingConfig" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:00:00.500"
                bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                maxBufferPoolSize="524288" maxReceivedMessageSize="65536000"
                messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                allowCookies="false">
                <readerQuotas maxDepth="32" maxStringContentLength="65536000" maxArrayLength="16384"
                    maxBytesPerRead="4096" maxNameTableCharCount="16384" />
            </binding>

        </basicHttpBinding>

Service config:

    <basicHttpBinding>
      <binding name="basicHttpBinding_config" maxReceivedMessageSize="5000000">
        <readerQuotas maxDepth="9000000" maxStringContentLength="9000000"
        maxArrayLength="9000000" maxBytesPerRead="9000000" maxNameTableCharCount="9000000" />
      </binding>
    </basicHttpBinding>

    <netTcpBinding>
      <binding name="tcpBinding_config" maxReceivedMessageSize="5000000" maxBufferSize="5000000" maxBufferPoolSize="5000000" >
        <readerQuotas maxDepth="9000000" maxStringContentLength="9000000"
          maxArrayLength="9000000" maxBytesPerRead="9000000" maxNameTableCharCount="9000000" />
      </binding>
    </netTcpBinding>

Any help is much appreciated! Thanks!

Jon

+2  A: 

The timeout exception is causing your proxy to go into a faulted state.

The reason why you do not get this exception with the BasicHttpBinding is because this binding does not use sessions. If there is an exception with a binding that uses sessions then the channel will become faulted and the session will get destroyed.

This tends to hide the real cause of the problem. One way to investigate the original exception is to use WCF Tracing.

WCF can be configured to output traces for process milestones across all components of the applications, such as operation calls, code exceptions, warnings and other significant processing events.

The following is a .config example to enable tracing.

<configuration>
  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Warning" propagateActivity="true" >
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>

      <source name="myUserTraceSource" switchValue="Warning, ActivityTracing">
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>
    </sources>

    <sharedListeners>
      <add name="xml" 
           type="System.Diagnostics.XmlWriterTraceListener" 
           initializeData="C:\logs\TraceLog.svclog" />
    </sharedListeners>

  </system.diagnostics>
</configuration>

Make sure the path defined in initializeData is writable by your service. You can read more about WCF Tracing from MSDN: Configuring Tracing.

Microsoft provides a Service Trace Viewer Tool to read .svclog files.

Daniel Vassallo
Thanks for your swift reply, Daniel!This was not quite the solution I was looking for, so I will allaborate my question further:In my client application (the ASP.NET site), I catch the error when communication with the WCF service fails. When I provoke (during debug) a Timeout scenario, I receive a TimeoutException when running the BasicHttp binding, but when switching to NetTcp binding (keeping everything else constant), it raises the "Faultet State" exception instead.So, I know what causes the error (namely a timout), so why doesn't the NetTcp binding report it?Jon
Jon Andersen
The reason why you do not get this exception with the BasicHttpBinding is because this binding does not use sessions. If there is an exception with a binding that uses sessions then the channel will become faulted and the session will get destroyed.
Daniel Vassallo
OK, so to recap; When using the NetTcp binding, I cannot catch a Timeout Exception from the channel? Is there nothing I could do in the endpoint / service configuration to disable sessions in the NetTcp binding? (I don't need sessions, so this could be a valid option for me).
Jon Andersen
I am not sure if you can configure the NetTcpBinding to deliver the original exception. In general, faulted channels are identified and handled accordingly: usually aborted and re-created.
Daniel Vassallo
OK, thank you for your time, Daniel! Much appreciated!
Jon Andersen