Session Timing Out

Sessions expiring after recently switching hosts

[RWSteele]

About a month ago I moved our clients to a new web host and now I'm having problems with sessions expiring. Whenever I login to the members area or admin area after a couple minutes I will get redirected back to the login page. This has happened in three different areas.

1) our current members area
2) a test forum
3) a test shopping cart

Even though I inherited this site, I'm prety familar with the code and did not have problems in the past with our other host.

Previously I was on Win 2000 Server and now I'm on a Windows 2003 server. I checked the session timeout in the global.asa and it was set to the default 20 mins. The tech I talked to confirmed that 20 mins. was also the default on the server and didn't have any ideas as to what could be causing the problems.

Am I forgetting something really simple? I don't want to waste time looking over all this code and find out it's something on the server. I've not worked with Windows 2003 until now so I'm not familar with any of the quirks or workarounds.

Thanks in advance for any suggestions.

[john_k]

The short advice is to check your log file.

There are three ways a session "times out"
1) The browser doesn't send the ASPSESSIONID cookie,
2) The browser doesn't make a request within the timeout period, and
3) The website application is restarted causing ALL sessions to become invalid.

Obviously, you need to make sure that your browser isn't causing this issue by not sending the cookie. Also, the browser might be fine, but if your website code is causing redirects across domains or subdomains, then the cookie may become lost.

As for 2 and 3 above, you might be able to determine which is happening to you by checking through your log file. In either case, I am pretty sure that the browser is going to present the ASPSESSIONID cookie. The server is determining that it is invalid and starting a new session with a new ASPSESSIONID. The actual name of the cookie (not its value) is unique to the Application instance. So if your application has restarted, then the letters after ASPSESSIONID will change. If the name stays the same, then the application has not restarted and the session has indeed timed out.

Probably more info than you wanted, but hopefully it will give you a few options to check into.

[duckhunter]

RWSteele, are you running your site on a SINGLE IIS box? We recently switched to a web-farm (multiple IIS boxes load balanced). Our host had to set the Sessions to "sticky" in the Load-Balancing hardware/software so that clients stay on the box rather than a click taking them to the page on a different server.

If you are settting Session.Timeout in your code and it's not working, something upstream is causing it.

[RWSteele]

john_k

Probably more info than you wanted, but
hopefully it will give you a few options to check into.

No problem. Remeber, information is power. ;)

duckhunter

"are you running your site on a SINGLE IIS box?

We're on shared hosting, but I don't know the much about their setup. I've also been having problems with this same site crapping out (twice in 2 days). I called to inquire about it they told me that mine was the only ASP site affected. I've picked up from the techs most the sites on the server seem to be running ColdFusion. One of them explained how they run in seperate memory space and that one couldn't affect the other, etc, etc. So I closed the forum and went code diving and found almost a dozen recordsets not disposed of. This isn't my code. I know better. :)

Any opinions on the CF vs .NET/ASP theory?

Our host had to set the Sessions to "sticky" in the Load-Balancing hardware/software so that clients stay on the box rather than a click taking them to the page on a different server

I know what load balancing is about and I know about the quirks that come along with it, but I've never had to deal with it before. Got any good tips or reading?

If you are settting Session.Timeout in your code and it's not working, something upstream is causing it.

SWEET! Before I get all cocky and start waving my six shooter around I want to make sure I have some real ammo. I know for a fact that the session timeout is set in the global.asa but what else should I check?

Thanks for all the input.

[duckhunter]

I would check with your host on their setup to find out if there are multiple boxes. If there are, each request could be taking you to a different box which starts a new session.

Also, running in your own memory space is definitely preferable, so I would ask for that. If your site still crashes while running in your own memory space, then it's probably somewhere in your code. If it never happenned before now and all that has changed is your host, I would question the server setup.

To prove Sessions aren't functioning properly to your host, create a simple ASP page that sets a Session Variable and another that writes it out with a Response.Write. If you are loosing session like you say, your response.write should yield nothing eventually.

[john_k]

your response.write should yield nothing eventually

Actually, when you lose the sessionid, IIS will create a new one. So, when the session is being lost, you will see a different sessionid.

If you are indeed using load balancing, and you are not accounting for it, then this is the cause of your problem.

Again, a quick check of your log file will bare this out. You would see ASPSESSIONID cookies being presented that do not match up. So in one log file you might see entries for ASPSESSIONIDABCDEFGHIJK= and also for ASPSESSIONIDLMNOPQRSTU=.

[RWSteele]

Thanks for all the feedback. It sounds like I was on the right track and thinking along the same lines as everyone else. I just wanted to make sure there wasn't any quirks with Win 2003 that would make ASP 3.0 gak.

I've looked over the log files and tried to filter out some useable info. While doing this I noticed the following lines which I assume is a server reboot.

#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2004-07-26 03:26:39

Here are the number of occurances for each log file.

7/20/04 12
7/21/04 8
7/22/04 13
7/23/04 9
7/24/04 9
7/25/04 13
7/26/04 9
7/27/04 13
7/28/04 6
7/29/04 9
Total: 101

Is this anywhere close to normal? Should I expect this from a established hosting company? I'm used to working with local web hosts who can't answer their phones, or employed with companies who have internal servers, so this is sort of new for me and just seems like alot of downtime. The time between the last page request and the restart time ranges anywhere from 15 minutes to 60 minutes. Maybe this would explain the problems with my sessions gaking?

Is this what I should expect in the "real world" from even the "big guys"?

Thanks again for the feedback.

[john_k]

Is this anywhere close to normal?

No. It is absolutely abnormal.

These lines are written by IIS when it initially creates the logfile OR whenever it restarts. So it is normal to see them at the top of each log file. If they occur anywhere else in the file, it means that the webservice or website was restarted. There is no ambiguity on this issue.

[duckhunter]

I would be concerned if it was rebooting once a week much less multiple times a day.

This is WAY beyond "normal". Find a host that provides some sort of guaranteed uptime. If ours is less than 99%, we start getting refunds on our monthly fees.

[RWSteele]

be concerned if it was rebooting once a week much less multiple times a day. This is WAY beyond "normal".

Got any ideas or advice regarding dealing with the downtime? Are the logs enough proof as to how much time we've been down?

Find a host that provides some sort of guaranteed uptime. If ours is less than 99%, we start getting refunds on our monthly fees.

They also guarantee 99.9% uptime. I guess it's time to pull out the calculator.

[john_k]

I guess it's time to pull out the calculator

Considering that they seemed uninterested in looking into the issue, and the frequency of the application restarts, and how many days have transpired, and that you had to invest quite a bit of time to hone in on something they SHOULD BE MONITORING, I don't think you should bother with a calculator. Tell them you want full credit for the entire month.

And start your new host quest immediately.

[RWSteele]

Considering that they seemed uninterested in looking into the issue...and that you had to invest quite a bit of time to hone in on something they SHOULD BE MONITORING

I haven't called them on this yet because I wanted to get feedback first. I'll make the call later today now that I have some ammunition, or at least more confidence. :)

Thanks again for all the input and I'll let everyone know what the outcome is.