Welcome to Vortx Community Forum, where you can ask questions and receive answers from the staff at Vortx and other members of the community.

If you had a user account on our previous forums website, you will need to register a new account here.

Learn more about...

AspDotNetStorefront
DotFeed

ipx.asmx timeout

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
asked Jul 19 in MultiStore by esedirect (415 points)

2 Answers

0 votes

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"

 

answered Jul 20 by mmcgeachy (4,310 points)
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.

0 votes

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!
------------------------------------------------------------------------------------------------------

 

answered Jul 24 by jsimacek (6,805 points)
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?
...