ipx.asmx timeout

Question

Hi guys, we've moved to a new server last week. We have a stored proc which is run through WSI ipx.asmx and we're now getting a timeout error for the response:

<Error Message="Exception, Message=Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding."/>

Running the actual sp in SSMS it takes 50secs, so I changed the ExecuteSQL to ExecuteLongTimeSQL(sql,100) but still get the error.

It's probably a setting that I changed years ago, but can't remeber/find it now.

Also added <add key="SQLCommandTimeoutSecs" value="120" /> to AppSettings.config

 

Any ideas how to overcome this please

Answer 1

Check your WSI client settings. When something has timmed out for me it has been the client timeout setings more than the server. Which gets down to adding some settings to a binding in the basicHttpBinding section.

For me adding the values below works fiarly well.

closeTimeout="00:05:00" openTimeout="00:05:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"

 

Comments

Is this on the server? And if so where, please? I'm assuming it because as I said earlier we've just moved the website to a new server.

Many thanks

---

No the pervious settings are for the WSI client. While there can be some WCF settings sever side that can cause issues in my exerpance those show up more when the response is large.

---

The response is fairly large, about 11.5mb and 25000 records - it's getting our product data for our back office system.

But I'm not sure what you're talking about the WSI client, since this hasn't changed - only the server.

---

Just because the server changed it doesn't mean that client changes are not needed either. Since responses can now be taking longer than what the client is used to. You can apply the binding settings the server 1st if you so desire.

Which the an example binding section would look like

<bindings>
	<basicHttpBinding>
		<binding name="httpBindingConfiguration" maxReceivedMessageSize="4096000" openTimeout="00:5:00" closeTimeout="00:5:00" sendTimeout="00:5:00" receiveTimeout="00:5:00">
			<readerQuotas maxArrayLength="262144" maxStringContentLength="4096000" />
		</binding>
	</basicHttpBinding>
	<basicHttpsBinding>
		<binding name="httpsBindingConfiguration" maxReceivedMessageSize="4096000" openTimeout="00:5:00" closeTimeout="00:5:00" sendTimeout="00:5:00" receiveTimeout="00:5:00">
			<readerQuotas maxArrayLength="262144" maxStringContentLength="4096000" />
			<security mode="Transport" />
		</binding>
	</basicHttpsBinding>
</bindings>

If that doesn't work than the same binding settings will very likely need to be set on the client also.

Answer 2

Did you guys get this resolved? The WSI Run command actually executes via the ExecuteSQL cart call, which times out after 30 seconds.

YOu could change the source code in the WSI.cs around line 1103 to be a ExecuteLongTimeSQL but that will be a source code change.

What Stored Procedure are you trying to run? Could it be optimized?

Thank you,

Jan

Compunix, LLC (Phoenix, AZ)
AspDotNetStorefront Development Partner and Reseller since 2005
------------------------------------------------------------------------------------------------------
 AspDotNetStorefront add-ons and plugins : http://www.ecommercecartmods.com
  * Searching Filtering, Single Signons, Reviews Ratings, Reports, Integrations

 Complete Automotive Solution : http://www.autopartsshoppingcart.com
  * Auto + Aftermarket Parts solution

 Unlimited Custom Development : http://www.compunix.us/t-unlimited-custom-development.aspx
  * Unlimited with Quick turn-arounds!
------------------------------------------------------------------------------------------------------

 

Comments

Eventually I re-wrote the SP. It was taking about 50 seconds and I got it down to 19. But I wasn't happy with that, so I wrote another sp which prepared the data into a new table about a minute before it was needed on a sql agent job. Then along comes the original sp which is called from one of our other sites to grab the data, which takes less than a second.

The disappointing thing is we've upgraded our hardware/OS/IIS/SQL Server and previously it wasn't timing out!

---

Good job on the rewrite! That is strange about the resources/power after upgrade...maybe it needs some optimization or host looking over it? It should only improve...who does your hosting?