views:

87

answers:

2

I'm connecting to a vendor-supplied web ASMX service and sending a set of data over the wire. My first attempt hit the 1 minute timeout that Visual Studio throws in by default in the app.config file when you add a service reference to a project. I increased it to 10 minutes, another timeout. 1 hour, another timeout:

Error: System.TimeoutException: The request channel timed out while waiting for
a reply after 00:59:59.6874880. Increase the timeout value passed to the call to
 Request or increase the SendTimeout value on the Binding. The time allotted to
this operation may have been a portion of a longer timeout. ---> System.TimeoutE
xception: The HTTP request to 'http://servername/servicename.asmx' has exceeded the allotted timeout of 01:00:00. The time allotted to this
operation may have been a portion of a longer timeout. ---> System.Net.WebExcept
ion: The operation has timed out
   at System.Net.HttpWebRequest.GetResponse() [... lengthly stacktrace follows]

I contacted the vendor. They confirmed the call may take over an hour (don't ask, they are the bane of my existence.) I increased the timeout to 10 hours to be on the safe side. However the web service call continues to time out at 1 hour. The relevant app.config section now looks like this:

   <basicHttpBinding>
    <binding name="BindingName" closeTimeout="10:00:00"
                    openTimeout="10:00:00" receiveTimeout="10:00:00" sendTimeout="10:00:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="2147483647" maxBufferPoolSize="524288" maxReceivedMessageSize="2147483647"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
     <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="2147483647"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
     <security mode="None">
      <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
      <message clientCredentialType="UserName" algorithmSuite="Default" />
     </security>
    </binding>
   </basicHttpBinding>

Pretty absurd, but regardless the timeout is still kicking in at 1 hour. Unfortunately every change takes at least an additional hour to test. Is there some internal limit that I'm bumping into - another timeout setting to be changed somewhere? All changes to these settings up to one hour had the expected effect.

Thanks for any help you can provide!

+1  A: 

This is some good guidance:

http://msdn.microsoft.com/en-us/library/ff647786.aspx#scalenetchapt10_topic14

Nissan Fan
+1  A: 

Firstly: See Steven Cheng[MSFT] response here about timeouts. There is a execution timeout you can set for httpRuntime. He says something interesting after that, which is "Also, make sure that you've set the 'compilation debug="false"' as to make the timeout work correctly"

Besides the fact that something may be terribly wrong on their end (or the data returned is so voluminous/ I'm not going to judge - might be a good reason), have you tried calling their operation Asynchronously? Same results? I guess it would take an hour

YourVendor.WebService ws = new YourVendor.WebService();
ws.LongRunningOperationCompleted += new YourVendor.LongRunningOperationEventHandler(ws_LongRunningOperationCompleted);

ws.LongRunningOperationAsync();

// Implement the ws_LongRunningOperationCompleted handler (stub will auto generate)

The completed event handler will have a specific event args param, which will contain the results, for event args e, e.Result should have what you need when it completes.

RandomNoob
The web.config file on the client's side had no httpRuntime element, so I added one with a very large timeout, then started it up again. We'll see in an hour, thanks!
Barry Fandango
As for the async option, I could open the hood and change the call to async. Are those generally more tolerant to timeouts, do they execute differently?The data is not too voluminous, but it has to be processed on the other end before the results are returned, and whoever wrote the processing code did not have an eye to performance past a certain data size.
Barry Fandango