I am using ASP classic (1.1) with IIS 6.0. Is there any options to set session never expire?
thanks in advance,
George
Session.Timeout=5
Would mean that it times out in 5 minutes. I don't think you can set this to infinity but you can set it to an approximately large number.
You can specify a Session.Timeout value in minutes.
Or have your pages poll the server every n minutes (a javascript function would do that, or you can have a dummy iframe with refresh-content set to call a dummy asp page every n minutes).
This is better (albeit polling can be taxing on your server, don't poll too often) because if you set your session timeout to a very high (or infinite...) value you'll end up with asp crashing with an out of memory error (I guess the application pool will be restarted).
The session is kept alive when the user calls any asp page on your application before the timeout expires. If your user closes its browser, there's no way your app will be notified and asp will have to wait for the timeout to clean the memory. That means that the session will stay in memory for n minutes after the user is gone, n being the timeout.
There's no need to have an infinite session (it can be addressed by polling) and tweaking with the timeout parameter will make your application more fragile.
If you want to store information for a long while (basically, for the whole life of your application) you'd better use the Application object, which is a dictionary just like Session but is a singleton and can be accessed by anyone on the server.
Steps for changing the website/ASP Session Time-out:
Open the IIS Manager from the Control panel.
Select your website
locate "ASP" under the IIS group in the right-side panel and double click for advanced properties.
locate time-out under Session Properties
Set session time-out as you needed.
Select Apply in the Action Pane to save the changes made.
furthermore, refer to the below screenshots
Related
I have an classic ASP site on IIS(both IIS 6,and 8) and both perform the same. We've had this issue for years on IIS 5,6,7,8 and never could figure it out. I have a time out setting on the IIS application pool settings of 120 minutes. I do not have a session.timeout setting in any of the ASP code itself. I do have a Session.Abandon in the global.asa file, which works well.
Most of the time if a user is idle for > 120 minutes, it gives them a message that their session has timed out, expires the sessions and redirects them back to the login page.. this is how it should work and most of the time is does.
The issue I have is that about 5% of the time, some users seem to be able to keep the session alive beyond the 120 minutes. Some for days.
I'm wondering if anyone has any ideas what could cause this? Some ideas that I think could cause this??
I assume they keep their browsers open for days, but could a user that has a browser window open but sitting idle AND on another TAB of that same browser be active on other websites? Does that activity make the TAB with my application still active/not idle? I've tested this on several environments but not able to replicate.
Some type of software like a URL filter, proxy server or Antivirus could be causing their browser to not be idle?
Of course a user can keep the session idle if they use the app beyond the 2 hours, but it is rather unlikely they do this, especially for days.
Its hard to troubleshoot since the users are all customers. So I have no clue if its a certain browser, browser version, or their network environment.
Any ideas?
have you tried out to set the timeout in the Application_OnStart method in global.asa?
I had a similar problem, but in my case the session ended up before timeout.
After I set up timeout the problem was solved, just including this line:
Session.Timeout=20
Hope it helps.
We have IIS 7 running a Classic ASP app and I've been noticing the following issue lately. Over the course of the day, if I look at Server Node --> Worker Processes some requests seem to fill up there. The elapsed time is something crazy like 12 hours at the end of the day. This requests all sit in the ExecuteRequestHandler stage.
There is no way anything is executing for that long, and I cannot seem to reproduce the issue. I have tried dumping w3wp.exe, using FRT, and all that good stuff, but I have some general questions:
Is there a setting that controls WHEN IIS stops a request? To be specific, in development, if I purposely design a page to be slow (i.e. update a SQL table thats locked) and then CLOSE out of browser, and monitor the requests in IIS, I see that the request still sits there for about 20 seconds before being removed. Is that 20 seconds a random interval, or can that be SET somewhere? To be clear, it's not that the page takes 20 seconds to execute, it will execute forever (in this test case) but it seems IIS gives up on it after 20 or so seconds after I log out.
Is there some way to see "orphaned" requests, I.E. requests in the app pool that nobody is waiting for anymore
What else can I do to try and debug this? A dump of w3wp says there are client connections with an HTTP request state of HTR_READING_CLIENT_REQUEST.
I keep getting suggestions of modifying IIS config settings such as AspRequestQueueMax, every time I try looking those up in the ApplicationHost.config I don't see those items set, so either I'm looking at the wrong place, or a default value would not be explicitly set in the config. This begs 2 questions: a) How do you READ these config values, i.e. get current value, b) how do you SET these.
A Classic ASP request will keep running until the script timeout is reached, regardless of whether the client is connected or not. I believe the default is 90 seconds, but an .ASP file can override this by setting the Server.ScriptTimeout property directly (which is pretty common). If your request queue is filling up then this is likely the reason and changing the defaults will not help.
If you can edit the ASP code, you can add logic like this in potentially long running sections:
If Not Response.IsClientConnected Then Call Response.End()
You can also global search your code for Server.ScriptTimeout to understand from where the abuse is coming.
If you do want to change the default script timeout, here is where it is stored:
https://www.iis.net/configreference/system.webserver/asp/limits
To change via the IIS7 GUI go to: (web site) > (features view) > ("IIS" category) > "ASP" > expand "Limits Properties" node > "Script Time-out"
I have a PHP application (although I suppose the general concept would be the same with web applications in other languages) that is supposed to destroy the user's current session after 300 seconds of inactivity. But is there a good way to test that this actually works? I started up my application and let it sit idle for 300 seconds, then clicked on a link and got redirected to the login page -- which is what's supposed to happen when the session is destroyed. Then I did the same thing after only 290 seconds and again I got re-directed to the login page. So either my timing was off, or there's a bug in my checking for session timeout, or there's a bug in my setting the length of time before session timeout. How do I figure out which one it is?
Also, is there a way that I can figure this out without having to wait for the application to timeout with each test? Thanks.
How about setting the timeout to something more manageable/testable like 30s?
As well, when you create a session you can log emit when it should expire. Set a stopwatch, and verify.
This is a bit of a throwback question, and probably relatively fundamental, but I'm at a loss.
How does IIS manage Classic ASP session state?
We have an app that stores user information in session, and when many users are using the app, it seems to be recycling session for users, even though the "expire period" has not elapsed.
We suspect that when a certain amount of memory has been used for the session state, it begins to recycle the oldest session objects or something like this.
If this is correct, is there some way to control for it with the existing application code?
Thanks!
ASP sessions are stored as simple in memory COM objects when the process hosting the ASP application are terminated so will all the sessions.
ASP does not "recycle" active sessions. However there are number of other circumstances which can affect ASP sessions.
Application Pool Idle Timeout
One phantom reason "Sessions" appear to timeout prematurely is because the "Sessions" in question are just under test during development. Hence whilst the developer is examining the content of a page or reviewing some code no further requests hit the site since its not actually a live site.
In IIS manager open the properties of the pool in which your ASP application runs. Take a look at the Performance tab. The Idle Timeout will default to 20 minutes. Hence if you have specified a session timeout of say 60 minutes and you are "testing" that timeout you actually discover your session has timed-out in 20 minutes. The lack of activity has killed the application pool.
Application Pool Recycling
IIS may recycle the application pool in which the ASP application is running in. Recycling means that the existing set of processes currently hosting the ASP application no longer accept new requests. New requests go to a new set of processes and the older processes will terminate when they have completed their outstanding requests.
There are a whole host of different settings and criteria that can be configured that trigger the recycling of an application pool. Take a look at the Recycling tab of the pool properties dialog.
If you think that there may be an excessive demand for memory then the Memory recycling section may indicate a cause.
Web Garden
An Application Pool can contain multiple processes to run the same set of applications. Back on the performance tab note the Web Garden section at the bottom. By default this is set to 1. However multiple worker processes will play havoc with ASP sessions. As noted above ASP session are simple in-memory COM objects. If subsequent requests for a specific session are dished out to different workers one worker will not have access to the session object that the other has.
Session.Abandon or Session.Clear
Logic bugs can sometimes be the cause of sessions apparently disappearing. Calling the above methods at an inappropriate point in a sessions life can cause a problem.
I have experienced the same thing. Session seems to be emptied of the data, meaning that no variables is no longer stored in the session, but since the session exists, On_SessionStart doesn't trigger.
Gives you a headache if you initialize data for a visitor that you later on depends on...
I have considered this a bug that no one seems to know about, and haven't found a solution to it. It seems related to memory-usage, as you point out, and the solution seems to be to make sure you don't have any leaks.
Implement object-caching in classic ASP memory-leaking
This issue for me turned out to be the number of worker processes under the Performance tab. It was set to 2 for some reason. We set it back to 1 and the issue went away.
The session timeout in web applications typically denotes the idle time - i.e. the period of time when the user doesn't work with the application.
Now, what if there is an automated script written that posts a request every 5 minutes - wouldn't that user's session go on endlessly? This being the case, won't this approach heavily load the application affecting its performance in the long run?
Running an automated call to the server, say via an AJAX request, will keep the session alive. Typically that's the point though. An interesting side effect of this is that if the request happens predictably and regularly, you can use it as a "ping" to determine if the user's browser is still open. If one or two pings are missed, you can close the session earlier and actually free up resources sooner than if you just let the session time out.
Yes, and Yes.
This is why if you're going to write an application for the web, you really want to find a way to implement it without using server side sessions. Usually, you will be able to find ways to implement the same functionality using cookies -- then the session data is client-side so who cares if they stay active permanently.
I did something similar for an application that relies heavily on session data.
What I did was set the IIS timeout to a relatively low number, say 10 minutes, then have a timed AJAX call that pings a blank page every 5 minutes.
This overhead on this is actually fairly low, as all you are doing is requesting a blank page, and if a person closes their browser, the session ends in 10 minutes.
You want to keep session as small as possible. That said, if everyone starts doing that, of course it will load your application, with(out) session. If you think your users are compelled to do that, consider why, as either your application is missing an important feature or is forcing them into something.
Now, regardless of that, if you are expecting lots of users to be active at the same time, so much than a single server won't do, then you would will end up having the session out of process. If the session is in Sql Server, it is just saved data, so in that case we wouldn't be talking about memory usage.
Well... I guess "It Depends" The first question you should ask yourself is whether you even need session.
If you have an automated process, my guess is that you don't really need to use session.
In that case, either turn it off or don't worry about it.
I guess your session table would be a little bit larger, but on the other hand you won't be tearing down and recreating the session. I don't see how this would "heavily load" the application. I suppose it would depend on the application itself and how much memory is used to maintain session state.
It would allow the use's session to go on endlessly, as long as they have their browser open. If need to keep a session alive for an extended period of time, you could also track the sessions via the DB and not in memory.
Also, if you are worried about the indefinite open session, you could implement a timeout from when the session opened and if there is an extended idle time.