I have hosted my application on IIS 6.0 and changed the idle time-out value and cookie state time-out values to 40mins.
But my application logs out after 30mins.
Why is this happening? Is there any upper limit to this?
Also, I cannot give 0(infinite) time out.
Related
I have a Web API application hosted under an on-prem (not Azure) IIS which logs to Insights and is showing Request durations very similar to the times reported in the IIS logs.
However, every so often, there is an entry in the IIS logs with a TimeTakenMS duration which is much longer than the Insights Request duration.
For example, a relatively simple request to read a small amount of data from the DB is logged with a total duration by Insights as 984.126ms but IIS is logging it with TimeTakenMS as 43718.
I have conclusively linked the two requests (they show a unique URL). I have eliminated application start up/recycle times (the application is clearly already started and serving other requests and the recycle boundary is hours away from the logged time stamps) and I have eliminated exceptions (Insights is not logging any exceptions at this time).
I also have a StopWatch set up in the controller for every web method and TrackTrace the elapsed milliseconds to Insights in a finally block, just before the method returns.
What other factors could cause an IIS hosted application to fail to log actual execution times to Insights but cause IIS to log much longer times?
I've considered network + processing time, but 42 seconds seems an unreasonably long duration (even for the start up time of this particular application.)
I am building a Blazor Server intranet application for my customer. One of the requirements is that they can stay logged in indefinitely. If they starting inputting some data on a Friday afternoon, they should be able to return on Monday morning and continue working without interruption.
I came to observe that the client-side was getting disconnected from the server about once per day. When this happened I would see the dreaded Blazor error “Reconnection failed. Try reloading the page if you’re unable to reconnect.”. If I click the link to Reload, it immediately reconnects to my server, but any work in process would be lost.
I found the root cause: by default, IIS is recycling the application pool every 29 hours. When this happens, the Blazor SignalR connection is getting interrupted, and hence the code running in the browser times out and disconnects.
I am able to work around this issue by disabling application pool recycling altogether. So far, it looks like that works fine (I could keep connectivity for the past 3 days). But I am worried this may not be safe long term, since application pool recycling helps deal with issues such as memory leaks, fragmentation, etc.
SO, my question is: is it possible to configure IIS in way that I can recycle the application pool AND also keep my blazor server connection available during that recycle period?
When you recycle an application pool, HTTP.SYS holds onto the client connection in kernel mode while the user mode worker process recycles. After the process recycle, HTTP.SYS transparently routes the new requests to the new worker process. Thus, the client never "loses all connectivity" to the server - the TCP connection is never lost - and never notices the process recycle.
I believe your problem is with the applications running in your application pool that store state within the process, such as whether a user is logged in or not. Everytime the process recycles, that state is automatically lost... which is by-design since that is what a process recycle accomplishes. As a result, your users "lose all connectivity" and "have to log back into their applications" to re-establish that lost state. The only way to fix this is for your applications to store its state outside of the IIS worker process such that it is friendly to being recycled.
The following blog entry talks more about what is going on:
https://learn.microsoft.com/en-us/archive/blogs/david.wang/why-do-i-lose-asp-session-state-on-iis6
I want to decrease request timeout in IIS. I already read these links
How to increase request timeout in IIS?
Default Limits for Web Sites
my issue is when I have an ASP.Net Core website on IIS and set timeout in limits to 20 seconds, it will go to 120 seconds and wont stop after 20 seconds. How can I define on IIS if processing request took more than 10 or 20 seconds then timeout and kill the process or recycle the related application pool?
I have an ASP.NET Core app — a RESTful API with websocket functionality through SignalR.
We have an issue when the application pool is recycled automatically every 29 hours - sometimes (rarely) it doesn't recover. Even manually, I can't restart the application pool.
Yesterday the only thing that helped was restarting the w3 publishing service.
By looking through logs I can see one moment the server responds nicely and fast with code 200 responses, then next it's all code 400 responses (?) and shortly thereafter 503.
Any idea what could be preventing it from recycling. The event log states in order:
A worker process with process id of '29752' serving application pool 'DefaultAppPool' has requested a recycle because the worker process reached its allowed processing time limit.
A worker process '29752' serving application pool 'DefaultAppPool' failed to stop a listener channel for protocol 'http' in the allotted time. The data field contains the error number.
Binary data:
In Words
0000: 800705B4
A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '29752'.
We've configured our application pool to recycle at a regular time interval of 180 minutes. But the worker processes are getting recycled every 60 minutes.
Is this a known issue, or do we need to configure something else?
Thanks
As stated in What causes an application pool in IIS to recycle?:
You might want to turn on full AppPool Recycle Event logs:
cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255
You also might want to take a look at this Scott Guthrie blog article: [http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx][1] that shows how to write code in Global.ASAX to log the actual cause of an Application.End event.