is there a default timeout set when i call a PageMethod from a javascript without specifying explicitly the timeout, if yes what is it?
Thanks
The standard XmlHttpRequest object has no built-in timeout mechanism. Ajax requests will go on indefinitely since there is no standard way to timeout. There are ways in which you can get around this however, which I would assume is what ASP.NET does in their framework.
IE8 is the only browser with a built-in timeout property, so I'm guessing that their Ajax framework would be consistent with that. In this case, the timeout would be indefinite by default.
ASP.NET also has an AsyncTimeout property for asynchronous page tasks, so it is possible that the framework would time out (server-side) in 45 seconds, which is the default for asynchronous tasks in ASP.NET pages.
There appears to be no default timeout from what I could find. If I were you though, I wouldn't rely on the default timeout length. You should specify your own length if you're concerned about timeouts. Timeouts can be indefinitely long by default. Users won't wait indefinitely long, so you're better off defining the timeout as the maximum wait a user should have to cope with (depending on the context).
UPDATE
I created a test page with a Page Method that will take 65 minutes to load (using Thread.Sleep()). The Page Method call waited the full 65 minutes, so it appears that my assumption was correct. Page Methods have no time out by default, or if they do, the timeout is over 1 hour. Don't forget that local development machines have effectively an infinite server timeout so ASP.NET will let a script run indefinitely. By default, the ASP.NET execution timeout for production configurations is between 90 and 110 secionts seconds depending on the .NET version you're running.
Related
We have some specific web pages and Web Api services which call long-running back end processes; and we'd like to carefully control when they should timeout.
I have created a simple MVC 4 site (in VS2012) with a page that sleeps for 200 seconds before returning. Then I set these timeouts:
(in web.config) : httpRuntime executionTimeout="120"
(in global.asax Application_Start) : Server.ScriptTimeout = 120
In IIS (7.5) Manager, I went to the site > Advanced Settings > Connection Limits, and set Connection Time-out to 120
I am not able to get this page to timeout. It successfully returns after 200 seconds without timing out at 120 seconds. I even tried using curl (disabling tcp keepalive) to take the browser out of the picture: curl --no-keepalive mysiteurl
First starting with what you already tried:
executionTimeOut=120 means when some operation is running on server and its takes more than 120 seconds to complete then that operation would time out, similar is the case for Server.ScriptTimeout. Connection Time Out specifies the time in which if a connection is not established the connection error would be returned.
That means the above error (execution time out) wouldn't happen unless a synchronous process takes over 2 minutes, or a ServerSide script runs for over 2 minutes, or the connection is not established.
What you can use.
I believe you should only be concerned with the session time out if you want the pages to time out in specified time. The other timeouts that you mentioned would work as expected, you can rely on them (refer this link if you want to test if the things are working or not).
If you are performing some db operations then you should consider altering you connection time out for db connection.
If debug mode is enabled, then these timeouts do not apply:
This time-out applies only if the debug attribute in the compilation element is False. Therefore, if the debug attribute is True, you do not have to set this attribute to a large value in order to avoid application shutdown while you are debugging (source)
We have a web page that calls a stored procedure. The stored procedure takes ~ 5 minutes to run. When called from ASP.NET, it times out at ~ 2 minutes and 40 seconds with an HTTP execution timeout error.
I tried setting an HTTP timeout property in my web.config file as:
<httpRuntime executionTimeout="600">
But it didn't help.
Any ideas appreciated. thanks
You should not create a web application with a page that could require such a long response time from the server. As a general rule, anything that you know will take longer than 10 seconds or so should be done as an asynchronous process. You've probably seen websites that display a "please wait" screen for long running processes, most times these pages work by delegating the long-running job to a background process or message queue, then polling until the job either completes successfully or errors out.
I know this may seem like a tall order if you've not done it before, but it really is the professional way to handle the scenario you're faced with. In some cases, your clients may be working from networks with proxy servers set up to abort the HTTP request regardless of what you've set your timeouts to.
This is a dated link, and I believe the .NET framework has introduced other ways of doing this, but I actually still use the following approach today in certain scenarios.
http://www.devx.com/asp/Article/29617
I'm working with ASP.Net web services and am having a problem with a long-running process that takes about 5 minutes to complete, and it's timing out. To fix this, I was able to set the executionTimeout on the server's web.config to 10 minutes, and then set the .Timeout property on the Web Service object to approximately 9 minutes. Now, I'm worried that this may possibly cause some other web service calls to sit there for 10 minutes before they time out rather than the previous 90-100 seconds. I know the default on the client side is 100 seconds, but wasn't sure if updating the server's timeout setting would affect this.
Bottom line is - Is it safe to update the server's timeout setting to a long amount like 10 minutes, and rely on the default timeout on the client, or could this end up causing some problems?
Thanks!
The web is not supposed to work like this. If you have a long running process, you should call it in a new thread and post the answer after the page has finish loading on the client side (either with a callback or by querying the server-side every x minutes to check if the process has finished). This way you avoid timeouts and the user gets their page (even incomplete) in a user-friendly time. This is important because if the user does not get their page in a reasonable time, they will be unhappy and try to reload the page (and maybe restart your process...).
when I access any page of my ASP.NET MVC website first time, then this first request is slow. It needs about 4-5 seconds to load. But every following request to any page is fast.
When I wait some minutes or a hour then every first request is slow again. Every following request is fast.
I think that IIS 7 is compiling the code and keep it in memory. After some time it will delete it from memory so it needs to compile it again.
What can I do that every first request is as fast as every following request?
(Without precompiling my source, if possible)
Thank you very much in advance!
If this is a production server then why not try adding a website monitor; such as up time robot. It basically asks for your websites headers and gets status codes like "200-ok", "404-not found", etc. every 5 minutes. This way your site is always spun up and does not impact log files/analytics as only headers are requested. I use this for my cloud sites as I find that they take 5 seconds to spin up which has an impact on site loading. With the monitor they are instant.
Oh and its free for up to 50 sites!
This could be the recycle worker processes setting on the application pool, check the value for that and either turn it off or make it longer.
Could also be the Shutdown worker process after being idle under performance for the application pool.
It's probably the second as that defaults to 20 minutes, the first one defaults to 29 hours I believe.
This is almost-certainly your app pool idle timeout setting (and not your code being recompiled).
The default app pool idle timeout in IIS is 20 minutes. Which means that, if 20 minutes pass and no requests come in to your app, IIS will shut down the worker process for your app pool, making your app "cold" again. Whoever makes the next request will be waiting several seconds as IIS restarts the worker process and "warms" your app back up.
If you don't want IIS to automatically "cool down" your app after a period of inactivity, you can disable the app pool idle timeout by setting it to 0.
Assuming that you have a regular stream of visitors, this should not be a problem in production. Also, unless you're physically altering any of your source files, IIS would not recompile it when it spins up your app.
Also, take a look at the .NET compilation settings available:
http://technet.microsoft.com/en-us/library/cc725812(WS.10).aspx
tl; dr
After quite extensive testing and gathering of relevant sources to attempt to resolve the issue, I think that the minimal solution may be (not verified) to add this code to the global.asax:
protected void Application_End()
{
...
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://web_domain.tld");
using (HttpWebResponse response = (HttpWebResponse)
request.GetResponse())
{
}
...
}
In the time of writing the post, this is used to effectevely maintain the site I worked on 'always-up' - with conjuction of setting the Idle Time-out (minutes) in IIS to 0 as mentioned in other answers. However I think that changing Idle Time-out (minutes) may not be necessary (assuming that Application_end event is raised when the switch of application pool to Idle mode occurs).
How it works (assuming it does):
There are 2 settings in the IIS application pool settings that affect when the application is suspended or terminated. One of them is Idle Time-out (minutes) which defaults to 20 minutes and when the specified time elapses since the last request, the worker process is suspended or terminated. When a next request comes, the worker process is resumed or started again and the Application_start event is raised (and so if the Application_start handler is defined in global.asax, it is executed). In case of the project I worked on, the Application_start took about 17 seconds to complete. So if the site was 'left alone' for 21 minutes and then the new request came, it took about a little more than 17 seconds before the response was sent back (Application_start + page processing). When another request was sent in the window of 20 minutes, the response was sent significantly faster (perhaps less than 1s), since the Application_start has already been processed.
Setting the Idle Time-out (minutes) value to 0 causes the worker process to never be suspended / terminated (at least due to the idle time - there may be another cause described below).
Apart from Idle Time-out (minutes), there is also the Regular time interval (minutes) setting in Recycling section of the IIS advanced settings. This defaults to 1740 minutes (29 hours) and is a regular scheduled task that causes the Application pool to periodically recycle (the period is fixed). This, I understood, is to prevent the accumulation of possible memory-leaks which, if present, may eventually crash the server by exhasting all the memory. The effect of app-pool recycling is that Application_end event is raised. However, after the application ends it is not automatically started again, so the Application_start event is not raised until an actual request comes (which is similar to the first case). So in the case of the aforementioned web application I worked on, it would again take about 17 seconds to process the first request to arrive after the recycling occured. Changing this value to 0 turns the recycling off, but I suppose that it is reasonable not to turn the recycling completely off due to the possibility of accumuluation of memory leaks over time (which may possibly even be caused by bugs in 3rd party libraries). I understand that the opinions differ on whether to set this value to 0 or not and may change over time.
Posible solution (without changing IIS settings):
If the requests are sent frequently enough, the app-pool may never switch to Idle mode. On the event of recycling, this would also cause to the application to start again. This can be achieved, for example, by using 3rd party service as described by #Rippo.
Proposed solution:
It has been observed that application pool recycling caused Application_end event to be raised. Assuming that it is also raised upon switching of the application pool to Idle mode, it would seem to be sufficient to create a request in the Application_end event handler to the website, which in both cases would then cause the application to start again (raising the Application_start event). The code is at the top of the answer.
I'm encountering a situation where it takes a long time for ASP.NET to generate reply with the web page (more than 2 hours). It due to the codebehind running for a while (very long, slow loop).
Browser (both IE & Firefox) stops waiting for the reply (after about an hour) and gives generic cannot display webpage error (similar to what you would see if you'd try to navige to non-existing server).
At the same time asp.net app keeps going (I can see it in debugger) and eventually completes.
Why does this happen? Are there any settings in web.config to influence this? I'm hoping there's a timeout setting that I'm missing that's causing this.
Maybe a settings in IE or Firefox? But I think they wait while the server is keeping connection alive.
I'm experiencing this even when I launch app in debug mode (with compilation debug="true") on my local machine from VS (so it's not running on IIS, but on ASP.NET Dev Server).
I know it's bad that it takes so long to generate the page, but it doesn't matter at this stage. Speeding it up would take a lot of extra work and the delay doesn't really matter. This is used internally.
I realize I can redesign around this issue running logic to a background process and getting notified when it's done through AJAX, or pull it to a desktop app or service or whatever. Something along those lines will be done eventually, but that's not what I'm asking about right now.
Sounds like you're using IE and it is timing out while waiting for a response from the server.
You can find a technet article to adjust this limit:
http://support.microsoft.com/kb/181050
CAUSE
By design, Internet Explorer imposes a
time-out limit for the server to
return data. The time-out limit is
five minutes for versions 4.0 and 4.01
and is 60 minutes for versions 5.x, 6,
and 7. As a result, Internet Explorer
does not wait endlessly for the server
to come back with data when the server
has a problem. Back to the top
RESOLUTION
In general, if a page does not return within a few
minutes, many users perceive that a
problem has occurred and stop the
process. Therefore, design your server
processes to return data within 5
minutes so that users do not have to
wait for an extensive period of time.
The entire paradigm of the Web is of request/response. Not request, wait two hours, response!
If the work takes so long to do, then have the page request trigger the work, and then not wait for it. Put the long-running code into a Windows service, and have the service listen to an MSMQ queue (or use WCF with an MSMQ endpoint). Have the page send requests for work to this queue. The service will read a request, maybe start up a new thread to process it, then write a response to another queue, file, or whatever.
The same page, or a different, "progress" page can poll the response queue or file for responses, and update the user, assuming the user still cares after two hours.
For something that takes this long, I would figure out a way to kick it off via AJAX and then periodically check on it's status. The background process should update some status variable on a regular basis and store it's data in the cache or session when complete. When it completes and the browser detects this (via AJAX), have the browser do a real postback (or get by changing location.href), pick up the saved data, and generate the page.
I have a process that can take a few minutes so I spin off a separate thread and send the result via ftp. If an error occures in the process I send myself an error message including the stack trace. You may want to consider sending the results via email or some other place then the browser and use a thread as well.