ASP.NET Session Time Out

I want to check if it is possible to override a .NET Application Pool's Process Model - Idle Time Out setting that is associated with my Discount ASP.NET hosted website?

I have read elsewhere on this forum that by default website sessions time out after 10 mins and not the standard 20 mins.

Is this setting configurable or is it something that cannot be changed? If it is configurable how do you go about changing the timeout setting?

 

No. That would defeat the purpose of the time out. Imagine the negative impact on performance if you had dozens (or hundreds) of sites on the server ignoring the time out. You wouldn't want your site hosted on that server.

That's not the case.

 

You would normally set application time out on web.config.

The 20 minutes limit is for application pool recycling event. That's when application pool goes to cycle process if no HTTP request made within 20 minutes (idle);however if you are using inProc mode to store session, it will lost along with application pool being recycled.

But session timeout though, it's set on your web.config.

Session is stored inProc model by default.
http://msdn.microsoft.com/en-us/library/h6bb9cz9(v=vs.71).aspx

 

In my case we will only be using InProc to store session. So the timeout setting in the web.config file is only useful if you want to set a session timeout less than the current corresponding Application Pool timeout of 20 mins which overrides the web.config timeout setting.

Thanks - just wanted to confirm your environmental settings.

 

Long time reader, first time poster. I have a small company website, and used to have an IT guy, but now we don't.

I'm searching for info on where to adjust time out settings. I'm pulling a report on my site, and keep getting a time out. I looked at web.config as mentioned above, but those limits are much higher than the time out I'm getting. Any suggestions where to find another time out setting? Thanks!

 

If you're seeing a timeout within the context of a single http request when you request a report from your web app, it sounds like your app pool is recycling. That will happen when your application resource usage exceeds the maximums. There are max limits for memory usage and CPU usage on an app pool documented somewhere.

 

Memory: >200mb
CPU: >70% for 5 minutes
Inactivity: 20 minutes

Generally speaking, any of those will recycle the app pool.

That's for Windows 2008/IIS7 servers. It's slightly different on IIS6.

 

Timeout issues

Hi Joe,
This is an interesting point, it may explain some problems I have been having when I try to upload larger volumes of data.
How can I tell or monitor if I have exceeded memory or CPU usage in my web application (I'm using ASP.NET, .NET 4.0 on IIS7)?
Thanks
MarcusT

 

Thanks Ray,
That's a good suggestion, I will follow up.
I did not have this problem on my local development environment (VS2010 in Win 7). Interestingly, in one case the entire data set of 10,000 rows was uploaded and inserted into the database, but then the server never returned the final report (works fine locally)... that's why when I saw memory exceeded issues, I though that could be the issue (I don't have this problem when I upload 1000 rows).
MarcusT

 

Thanks Ray, I appreciate your advice!
You mention that the transaction log may be filling up too quickly which doesn't give the system time enough to clear it... is there a way I can query the database for that information/status? If you can point me in the right direction, I can pull out my Sql Server books for details.
I can certainly try staggering the uploads, but what would be the appropriate amount of time between the uploads? 10 msec? 100 msec? 1000 msec? I'm not trying to be facetious here... I really just don't know!
Thanks again.

 

Sounds like a plan... I still have another 70,000 rows to upload... time to test!!
Thanks again.
MarcusT

 

Does the IIS6 servers have less memory allocated?

 

Yes, 100mb on IIS 6 and the application pool will recycle when the CPU usage is over 70% for 3.5 minutes, rather than 5 minutes on IIS 7.

 

Hi guys,
I'd like to come back to the issue of session timeout. My web pages are requiring a user to log back in after 20 minutes of inactivity. I have tried to change that several ways, including these statements in the web.config file at the top level of my app:

Code:

 <system.web>
    <compilation debug="true" strict="false" explicit="true"
       targetFramework="4.0" />

    <sessionState timeout="120"></sessionState>

    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>
    ....
  </system.web>

This does not change things. I even include Session.Timeout = 150 in my Login.aspx.vb code, and confirm the change by writing Session.Timeout to a text file.

Any suggestions?
Thanks.

 

You're hitting the 20 minute inactivity threshold for app pool recycle mentioned above. Changing the session timeout at application level in your web.config has no effect because app pool recycling is an IIS function whereas the session timeout settings are ASP.NET settings - IIS app pool recycling always wins.

Here's a suggestion that works - keep your app pool alive by ensuring there's always a minimal amount of activity on the site. You do this by creating a web page e.g. keepAppPoolAlive.aspx and then configuring the task scheduler to make regular requests to this page - more info: https://support.discountasp.net/KB/a166/scheduled-task-manager.aspx?KBSearchID=407830

 

Hi Joe,
Thanks so much for your answer... that sees to be the answer!

Pinging the server, either manually or with the task scheduler as you suggested, keeps the session from logging out. I assume that this 20 minute inactivity threshold for app pool recycling is immutable, so your workaround appears to be my best bet.

But now this brings me back to the earlier issue I was having... when I submit a web request, the page was never returning. So inserted a lot of code to write updates to a text file on the server as to what was happening, and it looks like the file upload, parsing, database operation and response generation are going smoothly.

What seems to be happening is that if that if the server side activity takes longer than 10 minutes, the page never returns. I am not logged out, there are no app errors that cause a recycle (discountASP.Net kindly provided the logs) but I wonder if there is some other "super secret" 10 minute timeout I am not aware of that blocks the response from coming back to my browser.

Thanks again Joe.
MarcusT

 

Yes this is a slightly different scenario. Have you tried the "Failed Request Tracing Module"? (a little more info here: http://community.discountasp.net/showthread.php?t=7375). If you've not tried it yet then it could be worth a go because it has the ability to provide an insight as to what causes requests to fail / time out.

 

Hi Joe,
Thanks again for your advice. I created the Failed Request Tracing Module as you suggested (I went to CP-> IIS Tools -> MS IIS Manager -> checked the box next to Failed Request Tracing and entered the name of a folder on my web share). Unfortunately (or fortunately), nothing shows up when I encounter my problem.

However, continuing my tracing, it is clear that the code-behind sub that is running the long process on the server has completed (the last line is to delete the file that was uploaded, and the file is indeed deleted). However, the browser is still hanging (circle is spinning, says "waiting for server...".

So there does not seem to be any error thrown, but the page never returns. I do not have this problem when the server-side processing only takes a under, say, 5-10 minutes. Happens with IE or Firefox.

Does this ring a bell to anyone?
Thanks.

 

Your problem got me interested enough to put a little test website together and publish it to my DASP account to see if I could reproduce your reported issue. It turns out that I'm unable to reproduce your problem but if it helps at all I do now have a working sample + source code to prove long running processes are working on the DASP server.

The longest test I've run that returned successfully and rendered it's complete response to the browser ran for 15 minutes at the server side. I've run this test in IE9, Firefox14 and Chrome21

You can run the test yourself hosted in my DASP account and download the source code here: http://crystalcmsc.eweb701.discountasp.net/LongRunningProcessTest/

 

Thanks a million Joe. Your site definitely works! I just got the source unzipped, and will study it to see what I can learn.
This is very generous of you, much appreciated, I'll let you know what I learn!
MarcusT

 

OK, following up:
Based on Joe's sample code, I included two extra lines of code in the "log me" subroutine in my code-behind file (this sub was originally writing updates to a scratch.txt file on the server):

Code:

Response.Write(String.Format(updateFromServerProcess & "<br>"))
Response.Flush()

With these two lines included, once the server process started, the browser screen clears and text (the updateFromServerProcess) appears on the screen.
After 8 minutes, the page is then re-presented, with all the data I wanted. (I was originally concerned I had maxed out some limit on data download... now I know this is not the case).

However, if I leave the "Response.Write" line out, then the request hangs, and the browser never receives an the final page. My scratch.txt file is there, showing the server process completed successfully.

Any thoughts on why that constant "dribbling" of data from the server to the browser is necessary to complete the round trip?

Thanks again Joe. Now there is a light at the end of the tunnel!

 

Since there doesn't seem to be anyone else chiming in with any suggestions here are my thoughts (again ;-)):

1. You've determined that your server side process is working to completion as you'd expect. The evidence to support this is your post#21 above that advises "the last line is to delete the file that was uploaded, and the file is indeed deleted"
2. We've determined that if your application server side process streams data directly to the client as it progresses, the server side long running process continues to completion and eventually returns successfully and renders the expected http response.
3. We've eliminated your application setup / web.config as the cause of the problem now due to (2) working. Both your application and my test application long running processes work when data is continuously streamed to the client - at the end of the long running process the response is rendered from the server.

Taking these things into account, I have to say that this is adding to up to looking suspiciously like the http network socket is being shutdown after some length of time when there's been no data transmitted / received. It looks like including the Response.Write / Response.Flush operations at various steps in the server side code are keeping the socket alive / open and active and is preventing whatever it is that wants to terminate the socket from doing so.

My assumptions here are based on what we've been able to see / prove so far but if I've guessed right, we still don't have enough to know if it's something on your local network or some device / process on the DASP host side that's terminating the connection. However we do know with certainty that if the server side keeps the connection active with trickle traffic, the connection stays alive and a successful response is eventually sent to the client at the end of the process.

 

Thanks Joe. You've articulated this very nicely.
To eliminate the culpability being with my local network, I will try to reproduce this behavior on other machines at other locations later today and tomorrow.
That leaves, as you say, some issue either at DASP, or some configuration of .NET that we are not aware of.
In terms of configuration, I have taken your advice and ping the my site every 15 minutes to keep the application alive. I also have the following timing settings in my main web.config.

Code:

 <system.web>
   ...
  <sessionState timeout="120"></sessionState>
   ...
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login.aspx" timeout="2880" />
    </authentication>
    ...
    <httpRuntime maxRequestLength="102400" executionTimeout="1200" />
    ...
 </system.web>

Perhaps one of these settings is guilty, or I am missing another key setting.

As background, my site is designed for a very small number of users, but with intense data exchange. Thus the large file sizes and long timeouts.

If any of the DASP team could weigh in on this, I'd be most appreciative.

 

Well after some 'out of the box' thinking and some digging around in IIS settings / headers, I believe I've found what's going on here. I've run some concurrent identical tests on my local IIS7 and also against the DASP web server IIS7 instance with a fiddler wire trace running and I noticed a slight difference in the http response headers from the DASP server. The http response from DASP includes this header:

Connection: close

Following up on this I found that the http standard (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.10) advises:

A little bit more digging led me to look at the Enable HTTP keep-alive setting in IIS7 which I found to be enabled locally (the default) but switched off on the DASP server - this I believe is the root cause of this problem. It's my understanding that when the server / web application trickles data back to the client as we have setup in our test application, the connection is considered to be active by the client browser and is therefore not killed off. However when there's no data coming back from the server, the browser respects the Connection: close header and after some period of time terminates the connection.

Here's some more info on IIS7 keep-alive:
http://technet.microsoft.com/en-us/library/cc772183(WS.10).aspx
http://www.dotnetscraps.com/dotnetscraps/post/Did-you-know-Enable-HTTP-Keep-alive-in-IIS-7-75.aspx

I've also found this old forum post referencing the IIS7 http keep-alive and the official line is that we're not able to enable this setting at application level for the reasons given.

I expect the best possible answer here (by way of a workaround) is to trickle data back from the server to keep the connnection alive as we've done. At least we know this definitely does work.

It would be great / much appreciated if a DASP staff member could confirm this is the cause of the problem being described here.

 

Hi Joe,
I'm sorry to see no reply from DASP on this. They are normally quite responsive.

In the meantime, as you said, the best answer here (by way of a workaround) is to trickle data back from the server to keep the connection alive. It turns out this has worked very well for me. In fact, the icing on the cake is that by using your technique, I can keep the user informed with regular updates from the server, as opposed to the the endlessly twirling circle, which is not helpful after 5 minutes of waiting.

So by replacing your javascript lines (which were very helpful) with simple html, I found I can essentially provide a one-line regular update and I can "clear the screen" before sending the final report page.

I start the reply with this:

Code:

Response.Write("<body>")
Response.Flush()

Then I run code like this on a regular basis, say after every 100 records are processed:

Code:

Response.Write("<script type=""text/javascript""> document.body.innerHTML = '';</script>")
Response.Write("Server is now processing record " & i & "; Last updated at " & Now.ToString & "<br/>")
Response.Flush()

And then at the end, finish with

Code:

Response.Write("<script type=""text/javascript""> document.body.innerHTML = '';</script>")
Response.Write("</body>")
Response.Flush()
Server.Transfer("FinalReport.aspx", True) 

I'm aware this is crude, and I'm sure there is a more elegant way to do this with AJAX, but I couldn't figure out how to do it without a timer, and the async postbacks interfering with the ongoing processing. I'm still new at this web stuff.

Anyway, I thought I'd put this out there for anyone else facing this issue. Thanks again for your input. This "workaround" ended a week of incredible frustration!

 

Hi Marcus I guess we can this a result then. It's funny that something I added as a bit of an afterthought in my proof of concept test application turned out to be the answer to this problem.

After we found this to work, I too at one point did consider an ajax call to enable progress notification but decided against it because an ajax call would spawn a separate http connection from browser to server and I rejected the idea at this point on the basis that the original connection would still be shutdown if not kept alive with trickle data throughout the long running process.

I'm still not clear what the root cause is on this one. I think we learnt enough to know with certainty that it's http connection shutdown related but after giving it some more thought, I'm not convinced that IIS keep-alive is the cause. At one point I enabled failed request tracing and like you found nothing conclusive - in fact when I took a look, everything looked healthy in the trace log so far as .NET application code is concerned even when there was no trickle data introduced. This means to track this further we'd need a level of logging which isn't going to be available to us in the shared server environment.

My gut feeling now is that it's either the DASP Windows Server 2008 host O/S or some other network device on the DASP side that's shutting the http connection / socket down when it's idle. I'm happy to hear you've found a reasonable solution though.

 

I'm sure Bruce or Ray will weigh in on this eventually, unfortunately server config isn't my forte. I do know that HTTP keep-alive was not exposed through IIS Manager initially because doing so would make connection quota management difficult.

I think that may change with Windows 2012/IIS 8 though, at least I recall hearing something to that effect in a recent meeting. Apparently IIS 8 has improved isolation or more isolation options than IIS 7 does, which makes it possible for us to expose more controls.

Or I could have been imagining that.