none
Explaination of different timeout types

    Question

  • When I configure a binding I can overwrite several default timeout settings.
    For example there are:
    • OpenTimeout
    • CloseTimeout
    • SendTimeout
    • ReceiveTimeout
    • InactivityTimeout
    • ...
    What exactly does each timeout stand for?
    The WCF documentation says "...timeout for an open operation to complete..." for the OpenTimeout for example - but what does this mean exactly?

    Maybe some of you can bring some light in this?

    Especially I want to know, which timeout to configure to achieve the following:
    A client tries to connect to a server service, but the server is not running at the moment - the caller should recognize this immediately.

    Which timeout do I have to minimize?

    Regards
    Bastian
    Tuesday, October 31, 2006 11:59 AM

Answers

  • Brief summary of binding timeout knobs...

    Client side:

    • SendTimeout is used to initialize the OperationTimeout, which governs the whole interaction for sending a message (including receiving a reply message in a request-reply case).  This timeout also applies when sending reply messages from a CallbackContract method.
    • OpenTimeout and CloseTimeout are used when opening and closing channels (when no explicit timeout value is passed).
    • ReceiveTimeout is not used.

    Server side:

    • Send, Open, and Close Timeout same as on client (for Callbacks).
    • ReceiveTimeout is used by ServiceFramework layer to initialize the session-idle timeout.

     

    For your specific question, if you are using a session channel that requires network interaction at Open() time, I would use OpenTimeout. 

    If not, you may have to use SendTimeout (but setting this to a small value would require all operation interactions to complete in a short period of time, which may be impractical if you are passing large messages or calling long-running request-reply operations).  Another option is to cast the client channel to (IContextChannel) and set the .OperationTimeout to a small value for only the first method call, but then set it back to a normal value for subsequent calls.

    Note that in a number of cases, you may get feedback even if the timeout doesn't kick in.  For example, using BasicHttpBinding (a simple non-session binding without RM), I find that if I invoke a client operation on a server that is not listening, I get an EndpointNotFoundException ("No connection could be made because the target machine actively refused it.") in a second or two, regardless of the timeout values.

     

    Tuesday, October 31, 2006 4:47 PM
  • The timeout indicated by the exception is that the service host is timing out.  That is, your application called host.Close() (or host.Dispose()) and that is what timed out (presumably because there were still client sessions connected).  The default is 10s.

    http://msdn2.microsoft.com/en-us/library/system.servicemodel.servicehostbase.closetimeout.aspx

    Saturday, February 17, 2007 10:16 PM
  • 1. The max timeout is on the order of 24 days, see

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1111927&SiteID=1

    for the syntax and the reason for the odd maximum value.

    2. Unfortunately I don't know the answer to this one.

    3. This is the 'callback version' of the transactionTimeout for the server.  Whereas the normal transactionTimeout on the server controls timeouts on transactions flowed from client to server, this one does the corresponding thing when flowing transactions from server to client when using a duplex callback contract.

    Friday, March 23, 2007 4:36 PM

All replies

  •  

    This blog entry touches the semantics behind the Timeouts.

    Dave

    Tuesday, October 31, 2006 4:43 PM
  • Brief summary of binding timeout knobs...

    Client side:

    • SendTimeout is used to initialize the OperationTimeout, which governs the whole interaction for sending a message (including receiving a reply message in a request-reply case).  This timeout also applies when sending reply messages from a CallbackContract method.
    • OpenTimeout and CloseTimeout are used when opening and closing channels (when no explicit timeout value is passed).
    • ReceiveTimeout is not used.

    Server side:

    • Send, Open, and Close Timeout same as on client (for Callbacks).
    • ReceiveTimeout is used by ServiceFramework layer to initialize the session-idle timeout.

     

    For your specific question, if you are using a session channel that requires network interaction at Open() time, I would use OpenTimeout. 

    If not, you may have to use SendTimeout (but setting this to a small value would require all operation interactions to complete in a short period of time, which may be impractical if you are passing large messages or calling long-running request-reply operations).  Another option is to cast the client channel to (IContextChannel) and set the .OperationTimeout to a small value for only the first method call, but then set it back to a normal value for subsequent calls.

    Note that in a number of cases, you may get feedback even if the timeout doesn't kick in.  For example, using BasicHttpBinding (a simple non-session binding without RM), I find that if I invoke a client operation on a server that is not listening, I get an EndpointNotFoundException ("No connection could be made because the target machine actively refused it.") in a second or two, regardless of the timeout values.

     

    Tuesday, October 31, 2006 4:47 PM
  • I think now I know which timeout to customize to get the result I want to. I have to play with it the next days to see how it works practically.

    But for now - thank you for the good explanation.

    Regards
    Bastian
    Wednesday, November 01, 2006 2:18 PM
  • I may be a little slow. I have a server side operation that may take a long time (a SQL stored procedure call). Right now I am getting an exception on the server side (from the trace log) that indicates it is a close timeout.

    The ServiceHost close operation timed out after 00:00:10.  This could be because a client failed to close a sessionful channel within the required time.  The time allotted to this operation may have been a portion of a longer timeout.

    The stack trace:

    System.ServiceModel.Channels.LifetimeManager.OnClose(TimeSpan timeout)
    System.ServiceModel.Dispatcher.InstanceContextManager.OnClose(TimeSpan timeout)
    System.ServiceModel.Channels.LifetimeManager.Close(TimeSpan timeout)
    System.ServiceModel.ServiceHostBase.OnClose(TimeSpan timeout)

    The binding:

    <wsHttpBinding>

    <binding name="httpBinding"

    closeTimeout="00:05:00"

    But if I change the server configuration to increase the server close time out I still get an exception. There must be something about timeouts that I still don't understand. As you can see the time out in the configuration file is longer than the timeout reported in the exception so either my timeout is being ignored or some other timeout is overriding the value that I set.

    Kevin

    Friday, February 16, 2007 5:11 PM
  • As some additional information that I have been able to find. I stepped into the server and found that the stored procedure actually ran quite fast but it returned over 11,000 rows. In the past I have received an exception that the number of bytes received is over the quota (on the client). In this case maybe the client is timing out before it figures out that there is too much data. If this is the case then it may be a client side timeout value that needs to be adjusted. Any ideas on which one?

    Thank you.

    Kevin

    Friday, February 16, 2007 5:34 PM
  • The timeout indicated by the exception is that the service host is timing out.  That is, your application called host.Close() (or host.Dispose()) and that is what timed out (presumably because there were still client sessions connected).  The default is 10s.

    http://msdn2.microsoft.com/en-us/library/system.servicemodel.servicehostbase.closetimeout.aspx

    Saturday, February 17, 2007 10:16 PM
  • If the service is closing what would cause the close to timeout? In my simplistic view close is like pulling the plug. It doesn't seem that this operation can timeout.

    Kevin

    Sunday, February 18, 2007 8:00 PM
  • When the service host tries to close, it tries to close all of its listeners; each listener will try to close any of its channels.  If a client is connected to a session channel that requires a handshake for a clean close, then this is the part that may timeout.  Additionally, there may be messages being processed at the time the host is Close()d; the host attempts to finish processing these as well.

    If I recall correctly, if host.Close() does get a timeout from trying to close its listeners, I think it catches the TimeoutException, traces it, and Abort()s the listener.  So, in effect, the host provides a short time (host.CloseTimeout) to get a 'clean' shutdown of everything, and then 'pulls the plug' after that.

    Sunday, February 18, 2007 10:06 PM
  • I've written a publisher subscriber, using a callback, and then pushing events to the client using the callbackChannel. That is, I store a collection of callbacks on the server. Everything works fine until I have a period of inactivity, where I don't pass data from the server to client, and the callback channel closes. I determined that I need to increase receiveTimeout to stop it closing, however I have  a number of questions:

    1. Whats the danger of increasing receiveTimeout, and how do I get above 23:59:00 which seems to be the max.

    2. Whats the inactivityTimeout of the reliableSession node for? Changing this has no impact on my project, I've enabled reliable sessions.

    3. What's the

    <callbackTimeouts transactionTimeout="23:59:00"/>

     under the endpointBehaviours section used for. Again this has no impact on my project.

    Thanks for helping!

     

    Friday, March 23, 2007 3:06 PM
  • 1. The max timeout is on the order of 24 days, see

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1111927&SiteID=1

    for the syntax and the reason for the odd maximum value.

    2. Unfortunately I don't know the answer to this one.

    3. This is the 'callback version' of the transactionTimeout for the server.  Whereas the normal transactionTimeout on the server controls timeouts on transactions flowed from client to server, this one does the corresponding thing when flowing transactions from server to client when using a duplex callback contract.

    Friday, March 23, 2007 4:36 PM
  • Thanks Brian. The 24 day timeout is sufficient for my needs, where the 23:59 hours was too small.
    Monday, March 26, 2007 7:24 AM