locked
Timeout? RRS feed

  • Question

  • I suspect a timeout problem on the client side and I don't know how to diagnose it. I was hoping that I might get some ideas from this forum.

    First, the reason I assume that it is a client timeout problem is that I can attach to the WCF service and stop on a breakpoint just before the 'return' which would esentially seriallize the object to be sent to the client. It reaches this point without error. But I end up with the error:

    System.ServiceModel.CommunicationException: The underlying secure session has faulted before the reliable session fully completed. The reliable session was faulted.
    
    Server stack trace: 
      at System.Runtime.InputQueue`1.WaitQueueReader.Wait(TimeSpan timeout, T& value)
      at System.Runtime.InputQueue`1.Dequeue(TimeSpan timeout, T& value)
      at System.ServiceModel.Channels.InputQueueChannel`1.Dequeue(TimeSpan timeout, TDisposable& item)
      at System.ServiceModel.Channels.DuplexChannel.TryReceive(TimeSpan timeout, Message& message)
      at System.ServiceModel.Channels.TransactionReceiveChannelGeneric`1.TryReceive(TimeSpan timeout, Message& message)
      at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
      at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
      at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
      at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    

    My client configuration to connect to the WCF service looks like:

    			<customBinding>
    				<binding name="NetTcpCustomBinding_IBsiServices" closeTimeout="00:04:00" openTimeout="00:03:00" receiveTimeout="00:50:00" sendTimeout="00:30:00">
    					<transactionFlow transactionProtocol="OleTransactions"/>
    					<reliableSession inactivityTimeout="00:30:00" maxPendingChannels="128" ordered="true"/>
    

    So the receive timeout is set to 50 minutes which causes the message to "work" and it returns in well under 50 minutes (usually 5-8 minutes). But decreasing this value to anything less causes the above error.

    The message log or the svclog on the client are not any help as they basically mimic the stack trace shown above. There has to be a better way than this trial and error for the timeout values (I see about 4 different timeout settings possible in the config file). Also (and probably more importantly) the time it takes to return from the message processing on the server doesn't seem to be correlated to the timeout values set in the config file.

    Ideas?


    Kevin Burton
    Wednesday, March 30, 2011 6:43 PM

Answers

  • Yea the SendTimeout is to Send, process, and get the response.  It is the entire timeout of a send operation from start to finish.  If that operation is two way (request-response) then it is like you said (and in your case this is true).  You would certainly want the above 120 seconds for this. 

    WCF has made that async part a lot easier than it used to be, but as you know it hasn't made it easier for us to convince other people how easy it is!.  I generally try to make services either return almost instantly or be async.  Part of that is because I do BizTalk a lot so the model and tools are more familiar (in fact forced) for me. 

    Also please remember, if my answers helped you, mark them as such.  Makes my days much happier!

    Kind Regards,

    -Dan

    • Marked as answer by KevinBurton Thursday, March 31, 2011 1:12 PM
    Thursday, March 31, 2011 1:11 AM

All replies

  • I did not think the receive timeout was used in client configurations.  But your open and close are much smaller.  The send timeout covered responses from request-response operations. 

    -Dan

    Wednesday, March 30, 2011 7:28 PM
  • So you are suggesting that I should update (increase) the open and close timeout? How do I decide which one to change? Send timeout is the amount of time it takes the client to send the request or recieve the response? Maybe it is a problem of mine in taking the frame of reference from the client.
    Kevin Burton
    Wednesday, March 30, 2011 7:38 PM
  • Well I'll start with this: SendTimeout is both the time to send the request AND the time to receive the response for Two Way operations initiated by the client.  On one way operations it is just the send time (note void operations are not always one way).  The configuration has all four on client and server (I believe for convinience / reuse) but the Receive Timeout is generally not used on the client, like I said I believe it is ignored. 

     

    If your operation is going to take many minutes it might be better to approach this another way, perhaps with asynchronous messages and a callback via Addressing.  I think that's the best answer. 

    -Dan

    Wednesday, March 30, 2011 9:45 PM
  • One more question. If SendTimeout is both the send and the receive time limit, does that include processing time? So if it takes 10 seconds to send the message, 100 seconds to process the message, and 10 seconds to send the response. Then in this case the total time to set SendTimeout to avoid a timeout would be greater than 120 seconds. Right? What would be the Open and Close timeout be for the client?

    I will consider refactoring to use asynchrous messages. I have a callback setup already it would be just convincing all the users of this web service to modify their code.

    Thanks again.

     


    Kevin Burton
    Wednesday, March 30, 2011 10:19 PM
  • Yea the SendTimeout is to Send, process, and get the response.  It is the entire timeout of a send operation from start to finish.  If that operation is two way (request-response) then it is like you said (and in your case this is true).  You would certainly want the above 120 seconds for this. 

    WCF has made that async part a lot easier than it used to be, but as you know it hasn't made it easier for us to convince other people how easy it is!.  I generally try to make services either return almost instantly or be async.  Part of that is because I do BizTalk a lot so the model and tools are more familiar (in fact forced) for me. 

    Also please remember, if my answers helped you, mark them as such.  Makes my days much happier!

    Kind Regards,

    -Dan

    • Marked as answer by KevinBurton Thursday, March 31, 2011 1:12 PM
    Thursday, March 31, 2011 1:11 AM
  • This is a WCF application that is several years old. How has async been made easier? Maybe this project is due for an upgrade?
    Kevin Burton
    Thursday, March 31, 2011 1:12 PM
  • The problem is that the client test is run using the

    Microsoft.VisualStudio.TestTools.UnitTesting;
    

    The tests that fail have the above stack trace. When the timeout is due to a test timeout VS usually shows 'Timeout' and I increase the attribute:

            [TestMethod]
            [Timeout(1200000)]
     

    But with the timeout like the above stack trace, it is my supposition that it is some kind of client side configuration timeout. Currently the SentTimeout is set to be

    			<customBinding>
    				<binding name="NetTcpCustomBinding_IBsiServices" closeTimeout="00:05:00" openTimeout="00:03:00" sendTimeout="00:35:00">
    

    But the 'duration' on the test run is much less than 35 minutes (14 - 19 minutes). I am not still not sure which timeout to adjust. It looks like going async for these messages would be the way to go but I would like to get it working as is first. If for none other reason than to understand what the configuration settings do.


    Kevin Burton
    Thursday, March 31, 2011 1:26 PM