john_k
msg:946798 | 2:58 pm on Jul 28, 2004 (gmt 0) |
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
msg:946799 | 6:02 pm on Jul 28, 2004 (gmt 0) |
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
msg:946800 | 12:11 am on Jul 29, 2004 (gmt 0) |
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
msg:946801 | 12:19 pm on Jul 29, 2004 (gmt 0) |
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
msg:946802 | 2:22 pm on Jul 29, 2004 (gmt 0) |
| 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
msg:946803 | 3:23 pm on Jul 29, 2004 (gmt 0) |
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
msg:946804 | 3:30 pm on Jul 29, 2004 (gmt 0) |
| 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
msg:946805 | 5:04 pm on Jul 29, 2004 (gmt 0) |
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
msg:946806 | 9:29 pm on Jul 29, 2004 (gmt 0) |
| 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
msg:946807 | 3:47 am on Jul 30, 2004 (gmt 0) |
| 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
msg:946808 | 1:51 pm on Jul 30, 2004 (gmt 0) |
| 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.
|
|
