Anders Lybecker

Engineering lead at Microsoft helping strategic important customers with their digital transformation journey to the cloud.

1 minute read

Note: This post refers to .NET Framework for Windows only, and not for the cross-platform .NET Core or simply .NET as it is re-branded in 2020. This means this post is outdated for newer version of .NET

Timeout

The last two articles about WCF Throttling part 1 and part 2 would not be complete without looking at WCF timeouts. Any potentially lengthy operation must have a timeout or the system might end up waiting indefinitely – this is remarkably prevalent when working across any network connection (Yes, LAN connections too).

Timeouts are not directly related to throttling properties, but effect the way the service (or client) performance under load. Timeout properties can be perceived as an annoyance when sending larger messages or dealing with slow connections or services. The frustration increase as the naming of the properties can be deceiving. Read on… and I’ll explain 🙂

Below are the binding properties that all throw TimeoutExceptions if any of setting thresholds are exceeded:

  • OpenTimeout (TimeSpan) the interval of time provided for an open operation to complete including security handshakes (WS-Trust, WS-Secure Conversation etc.). The default is 00:01:00.
  • CloseTimeout (TimeSpan) the interval of time provided for a close operation to complete. The default is 00:01:00.
  • SendTimeout (TimeSpan) the interval of time provided for an entire operation to complete. This includes both sending of message and receiving reply! The default is 00:01:00.
  • ReceiveTimeout (TimeSpan) the interval of time that a connection can remain inactive, during which no application messages are received, before it is dropped. The default is 00:10:00.
    • This setting is only used on the server-side and has no effect on client-side.
    • When using Reliable Sessions remember to set the InactivityTimeout property on the reliableSession element to the same value as the ReceiveTimeout property, as both inactivity timers has to be satisfied.

Example of configuration file:

<system.serviceModel>
  <bindings>
    <netTcpBinding>
      <binding name="netTcpBindingConfig"
               openTimeout="00:01:00"
               closeTimeout="00:01:00"
               sendTimeout="00:01:00"
               receiveTimeout="00:10:00">
        <reliableSession enabled="true"
                         inactivityTimeout="00:10:00" />
      </binding>
    </netTcpBinding>
  </bindings>
</system.serviceModel>

Comments

You May Also Enjoy