In IIS7 Application Pool there is a setting Idle-time out default is 20 min,
which says:
Amount of time(in minutes) a worker process will remain idle before it shuts down, A worker process is idle if it is not processing requests and no new requests are received.
My question is, if the worker process shut down because of the time-out time, does the session created by application which is hosted in this worker process get lost?
Yes -- the session data is tied to the app pool worker process, so once the worker gets shut down, the session data is lost.
The default behavior is to store session variables in the memory space of the ASP.NET worker process.
(Of course, this assumes you're using InProc as the session mode. If you're using the database, then it will persist after the worker gets shut down.)
Related
I have an ASP.NET (.NET Framework) site running in IIS. The site has a long-running background process and when the application pool is stopped as part of tearning down an active VM I'd like for the w3wp process to continue running until the background process shuts down gracefully (which can take a long time).
We leverage a custom IRegisteredObject to plug into ASP.NET shutdown; our code does not return from the Stop(true) call until the background process shuts down.
When we stop the application pool, we see in our logs that Stop(false) is called and then Stop(true) is called 30s later like we expect. However, before Stop(true) returns IIS is simply killing the worker process. This kill happens five minutes after the initial Stop(false) call. We'd like to extend this timeout.
In IIS itself, we have App pool->Process Model->Shutdown Time Limit to 1000s. Lowering this value below 5 min can make the kill happen sooner, but raising it above 5 min does not prevent the kill at 5 min.
Is there some other timeout setting that governs this shutdown? Is it possible to go beyond 5 minutes?
The shutdown time limit hint leaves the old worker process running for up to the number of seconds indicated. If all requests are completed prior to that time, then it will shut down earlier. this is why you lower the value below 5 minutes to make the killing happen sooner.
And the maximum shutdown timelimit seconds appears to be 4294967, this is more than 5 minutes, But if there is not enough free memory, it will cause no more than 5 minutes.
Recently, some of my IIS application is having no response. I check the event log and found that some
error happened in WAS service which cause some application pool to be stopped.
The following is the error message.
I can see only the process id causing
the problem.
I checked the error and find in one apppool a process is exceeded time limits during shut down.
Is that possible the process cannot shutdown and cause the other apppool to shutdown. My solutions is set the Test_pool application pool timeout to 1440 minutes(24 hour) and set recylcing time at a specific time
of the day to avoid the shutdown failure of process and prevent the auto shutdown of application pool. Is that workable?
A process serving application pool 'CEHL_POOL' exceeded time limits during shut down. The process id was '529004'.
A worker process '504596' serving application pool 'TEST_POOL' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
A worker process with process id of '794136' serving application pool 'TEST_POOL' was shutdown due to inactivity. Application Pool timeout configuration was set to 20 minutes. A new worker process will be started when needed.
Application pool 'TEST_POOL' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
The event logs included mutiple errors with different application pool. So please point out which application pool stop responding. The error message "exceeded time limits during shut down" means the application failed to finish all current requests inside the process before application pool shutdown timeout reached. So either threads hang up or locked up.
“being automatically disabled due to a series of failures。。。”is caused by rapid failure protection, so you need to check application events and you should be able to find the crash event.
No matter crash or hang, you need to reproduce the issue and monitor the request status inside worker process monitor. It will show the time taken and current handler. You may need to collect and analyze dump file to trace the root cause.
Besides, in some case, http.sys will cause this issue because it is no longer able to wake up a new appliction pool. You may need to check whether your application pool is able to be waked up after your application stop responding.
I have a Window Presentation Framework application that uses web services to load data in user interface. I notice that when i leave my application idle for 10 min and access my application again, my application is not responding for 3-10 sec. After some research i choose to set my application pool idle timeout in Internet Information Services to 0 and my problem solved. I have some understanding that after i leave my application idle for 10 min, my OS will free up the memory resource that allocate to my web services processes but i still have some doubt on this.
My question is
1) The default idle timeout is set to 20 min, why the OS terminate my process after i left my application idle for 10 minute only?
2) During the first time when i log in to my system, why there is no "not responding" issues given that the application just started to call the web service? I assume the application will need to call the web service again after i idle for 10 min and the OS terminate my process but this time my application become not responding..
I'm running a very high traffic site that gets a good 300+ requests/second (http://cooltext.com). A restart takes a good 90 seconds at least for it. So every time I post a new build it goes down for a minute or two. Long enough to trigger my monitoring services.
When I make a change that restarts the server, it appears that the restart stalls until all of the old requests on the old application pool (some of them very long running) complete. I can make the restart happen much faster by killing the old w3wp.exe instance manually.
Is there some way to force IIS to close all the connections right away and do a hard restart? Some setting in IIS or asp.net to control this?
Just found the following that appears to be what I'm looking for: http://msdn.microsoft.com/en-us/library/aa720127(v=vs.71).aspx
Shutdown Time Limit is the equivalent application pool setting for the shutDownTimeout ASP.NET process model setting. It specifies the amount of time a worker process is given to shutdown gracefully. If the worker process does not shutdown in time amount specified, the ASP.NET ISAPI will end the worker process. Shutdown Time Limit is set to 90 seconds by default. You can specify a different time limit by changing the value in the spin box.
When recycling happens, I want to move all new request to new w3wp (this is done automatically) and leave the previous w3wp to exit when it gets idle (whatever time it takes).
There's a shutdown time limit config for application pools (I use IIS 7.0) which doesn't take 0 as a value. How can I let the previous w3wp to shutdown when it is done and idle.
The shutdown time limit hint leaves the old worker process running for up to the number of seconds indicated. If all requests are completed prior to that time, then it will shut down earlier.
When recycling happens, a new worker process spins up and immediately begins taking new requests. The old worker process continues working on old in-flight requests until completed, or until the shutdown timelimit is reached. By the way, the maximum shutdown timelimit seconds appears to be 4294967 which is one second shy of 50 days. OMG I hope no one is waiting that long for a request to complete!
Parenthetically, it is possible for a new worker process to NOT actually be able to start, especially if there is not enough free memory.