Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > .NET > .NET 1.0 and Visual Studio.NET > VS.NET 2002/2003
Password Reminder
Register
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
VS.NET 2002/2003 Discussions about the Visual Studio.NET programming environment, the 2002 (1.0) and 2003 (1.1). ** Please don't post code questions here ** For issues specific to a particular language in .NET, please see the other forum categories.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the VS.NET 2002/2003 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old April 7th, 2004, 03:56 PM
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default Session Variables Randomly Disappear?

I have a problem where all my Session variables seem to just disappear for no apparent reason. SessionState is enabled for the application with a 20 minute timeout. All code resides in the same project in the same subdirectory on the same server. To make matters worse, it's not reproducible on demand - sometimes it happens upon entering a page, other times it occurs when clicking on a postback control, but I can't seem to predict when this will happen. I can follow the very same steps from one session to the next, and one time they'll disappear and the next they'll be there. It makes no sense.

It almost feels like it's timing out, except this is happening sometimes within seconds of starting the session, not 20 minutes later as teh timeout value would seem to imply. Response.Writes on each form show the very same session id, so it's not like it's trying to start a new session. I'm stumped and ready to abandon session variables in lieu of storing this information in my database. Any clues or other suggestions?
Reply With Quote
  #2 (permalink)  
Old April 9th, 2004, 09:35 AM
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default

I must be the only person in the world with this problem. If anybody should stumble across this question searching the web and wants to write to ask me how I solved it, the answer is that I haven't. Instead, I've developed code to encrypt the querystring and abandoned using session variables due to apparent unreliability.

Good luck to anybody else who finds themselves faced with this. If you discover a solution, I'd sure be interested to hear it, but I don't have one and am out of time.
Reply With Quote
  #3 (permalink)  
Old April 9th, 2004, 10:06 AM
Imar's Avatar
Wrox Author
Points: 72,055, Level: 100
Points: 72,055, Level: 100 Points: 72,055, Level: 100 Points: 72,055, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 17,086
Thanks: 80
Thanked 1,587 Times in 1,563 Posts
Default

When I first read your post, I was quite intrigued by the problem. I used to have this exact same issue with classic ASP pages a long time ago, so I understand the frustration.

The only I can think of that may cause this problem is IIS's Process Recycling feature. In recent versions of IIS (2003 for sure, maybe 2000 as well), the IIS process is recycled every now and then to prevent memory leaks and performance problems. I can imagine that with a setting of InProc (not sure if that's default), the Session values go down with IIS.

I am not sure if this is a) true at all and b) the cause of your problem, but it's worth a try. Look into the IIS log files, and you'll seen when the server restarted. If these times are roughly the the same as the time your variables got lost, that might explain the reason of your problem.

Just my 2 cents....

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Green Calx by Aphex Twin (Track 6 from the album: Selected Ambient Works 85-92)

Reply With Quote
  #4 (permalink)  
Old April 9th, 2004, 03:38 PM
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default

Thanks for the suggestion. Although I've already changed my code, I did look for the log file as you suggest. What I found was this:

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2004-04-08 13:11:28
#Fields: time c-ip cs-method cs-uri-stem sc-status
13:11:28 127.0.0.1 DEBUG /SISO/frmPinput.aspx 200
13:11:28 127.0.0.1 GET /SISO/frmPinput.aspx 200
13:11:31 127.0.0.1 POST /SISO/frmPinput.aspx 302
13:11:31 127.0.0.1 GET /SISO/frmsigninout.aspx 200
13:11:34 127.0.0.1 POST /SISO/frmsigninout.aspx 302
13:11:34 127.0.0.1 GET /SISO/frmPersonalInfo.aspx 200
13:11:37 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:39 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:39 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:40 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:40 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:40 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:41 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:41 127.0.0.1 POST /SISO/frmPersonalInfo.aspx 200
13:11:45 127.0.0.1 DEBUG /SISO/frmPinput.aspx 200
13:11:48 127.0.0.1 DEBUG /SISO/frmPinput.aspx 200

Is this the kind of log file you're talking about? And if so, do you know of a site where I can fidn a list of the sc-status codes to determine what they mean?

Thanks again for your assistance.
Reply With Quote
  #5 (permalink)  
Old April 9th, 2004, 03:51 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

From memory I can tell you that 200 is "OK" and 302 is a redirect command.

To confirm Imar's statement: I too have heard about IIS recycling on its own. We use SQL based session management, but my site uses InProc and I have seen odd occurances of this nature. About the only thing you might be able to do is try noting the time when you see this happen and keep a log of the times. See if there is some pattern to them, like a 20 minute cycle.

I'd definately like to find out more about this. Anyone from Microsoft care to chime in??

Peter
-------------------------
Work smarter, not harder
Reply With Quote
  #6 (permalink)  
Old April 9th, 2004, 04:24 PM
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default

At the end of my attempt to debug this, I was starting to note the times when this occurred relative to the time out period because it felt like the two were connected somehow. What didn't make sense was that the session IDs were different between runs and the timeout period should therefore have been reset. Then I tried dropping the timeout period to two minutes instead of 20 to see if I could get it to happen more frequently, but that didn't seem to make a difference. So, it feels like what you're suggesting is right. I just need to figure out how to interpret the log files to confirm it. It might be easier to simply find this setting and adjust it, or perhaps I should store the session variables in cookies instead of inproc?
Reply With Quote
  #7 (permalink)  
Old April 10th, 2004, 09:15 AM
Imar's Avatar
Wrox Author
Points: 72,055, Level: 100
Points: 72,055, Level: 100 Points: 72,055, Level: 100 Points: 72,055, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 17,086
Thanks: 80
Thanked 1,587 Times in 1,563 Posts
Default

Hi Ron,

The logs you posted actually consists of two parts: a header and the actual page requests. The header (see below) can appear multiple times in the same log file, and is written every time the IIS process starts.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2004-04-08 13:11:28
#Fields: time c-ip cs-method cs-uri-stem sc-status

So, when you boot and request the first page in your site, restart IIS manually or when the IIS process is recycled, you'll see this header appear in your log file. If you see many headers for the same date, you're probably using process recycling. You can also see the date and time the process was started. If the date and time more or less matches the date and time your session values are lost, you probably found the cause of the problem. In Windows Server 2003, you'll find this setting on the Properties for the Application Pool your application is using. Can't remember where exactly it is locate on Windows 2000.

The other part of the log files contains the actual hits. You'll see the time and the client's IP address (c-ip), the method (Post, Get, etc), the URL of the page (cs-uri-stem) and the status. Look in the IIS help for a full description of all error codes and info about the logging and other stuff you can log.

Storing "the session variables in cookies instead of inproc" isn't really the way things work. A cookie is used to track the ID of the sessions, so when you visit another page in your application, IIS is able to hook up your request to the existing session object that holds the session values. This object always needs to be saved on the server. How this session object is stored is important. InProc means it's saved within the IIS process. StateServer uses a different stateserver, a process (a Windows Service) that can run on the same or another computer and that does not go down with IIS. The third alternative is to use a database, as Peter suggested.

I think you're best off using the StateServer setting as it will protect your session variables without the need to set up the state server functionality in SQL Server.

UPDATE
The IIS Process Recycling on Win2000 is an add-on. See here for more details:
http://www.microsoft.com/downloads/d...DisplayLang=en
That also makes it less likely you have it enabled, though....

Hope this helps,

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Faces And Names by Lou Reed & John Cale (Track 7 from the album: Songs For Drella)
Reply With Quote
  #8 (permalink)  
Old April 12th, 2004, 08:29 AM
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default

[quote]Originally posted by Imar
 Hi Ron,

The logs you posted actually consists of two parts: a header and the actual page requests. The header (see below) can appear multiple times in the same log file, and is written every time the IIS process starts.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2004-04-08 13:11:28
#Fields: time c-ip cs-method cs-uri-stem sc-status

So, when you boot and request the first page in your site, restart IIS manually or when the IIS process is recycled, you'll see this header appear in your log file. If you see many headers for the same date, you're probably using process recycling. You can also see the date and time the process was started. If the date and time more or less matches the date and time your session values are lost, you probably found the cause of the problem. In Windows Server 2003, you'll find this setting on the Properties for the Application Pool your application is using. Can't remember where exactly it is locate on Windows 2000.

Ron replies:
Imar,

Thanks for the detailed explanation - this is better than anything else I've been able to find so far anywhere on the web. I've checked the log files and don't see any apparent regular restarts of IIS ocurring. To verify it, I tried restarting IIS and sure enough, I got another set of headers. Although I am seeing multiple headers in one or two log files, they don't appear to be consistently occurring at regular intervals, and more likely are associated with reboots to my development system for various reasons. I certainly don't see multiple ones coinciding with this particular problem, although that's difficult to say for certain because the time stamps on the log records are not recording the correct time (it appears to be off from the system clock by almost 6 hours - very strange). It almost appears as though the files are not complete, because I could swear I've made multiple calls over and over on some days trying to reproduce this problem and the log files don't seem to show that many requests, but it's hard to be sure with this time issue. Anyway, I can't find the Application Pool to check it's settings, but based on the fact that I'm not seeing multiple headers at regular intervals, this wouldn't appear to be the issue anyway.

Storing "the session variables in cookies instead of inproc" isn't really the way things work. A cookie is used to track the ID of the sessions, so when you visit another page in your application, IIS is able to hook up your request to the existing session object that holds the session values. This object always needs to be saved on the server. How this session object is stored is important. InProc means it's saved within the IIS process. StateServer uses a different stateserver, a process (a Windows Service) that can run on the same or another computer and that does not go down with IIS. The third alternative is to use a database, as Peter suggested.

I think you're best off using the StateServer setting as it will protect your session variables without the need to set up the state server functionality in SQL Server.

Ron replies:

Thanks also for this explanation. Session variables are a sort of black box to me - I just expect them to work and didn't think I'd need to know so much about their gory details. At this point I'm concerned about their reliability regardless of where they're stored, and as I've changed my code back to using encrypted querystrings, I'm reluctant to change back to session variables where ever they're stored without knowing with certainty that they'll work, as this will jsut put me further behind on this project. I think I'll just stick with a poor work around over something that just doesn't seem to work. Once I get done with this project, I'll probably rebuild the development box with the latest VS version, and maybe this'll just magically go away then.

Thanks again for your help with this.
Reply With Quote
  #9 (permalink)  
Old April 12th, 2004, 09:27 AM
Imar's Avatar
Wrox Author
Points: 72,055, Level: 100
Points: 72,055, Level: 100 Points: 72,055, Level: 100 Points: 72,055, Level: 100
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 17,086
Thanks: 80
Thanked 1,587 Times in 1,563 Posts
Default

Hi Ron,

I am glad you appreciate my posts.

If you're using W3C logging, it makes sense you're seeing odd times, as it uses Greenwich Mean Time be default. I am not sure, but I think this is done so you can compare logs located at different servers in different timezones. 4 o'clock is 4 o'clock then.

What you could do is setup Sessions using a separate StateServer (easy to configure in the Web.Config file) and then just use a few test variables. Set on in Session_Start and see how it behaves throughout your application. If it works, you can then start using it for other purposes as well. This way, you can keep working with your work-around while testing the reliability of Session variables.
Personally, I haven't ever noticed the behavior you describe, although I do use Sessions here and there.

The fact you're not seeing each and every log is quite possible. If the page is cached by the browser and / or an intermediate proxy / caching server, it's quite possible the page doesn't show up in your logs. If you test out stuff like this, always use Ctrl+Refresh in IE to force a fresh page from the server.

Cheers,

Imar

---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Girl You Have No Faith In Medicine by The White Stripes (Track 13 from the album: Elephant)

Reply With Quote
  #10 (permalink)  
Old April 26th, 2004, 12:18 PM
Registered User
 
Join Date: Apr 2004
Location: , , .
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default

I just recently found this thread, and although my application is classic asp I thought I'd post a note in case anyone finds a solution. In my application, we track the user id from a SQLServer database (along with many other session variables). The timeout is set in the session.On_Start at 60 minutes, but the same random loss of session variables is turning up. Every page in the site checks the value of the UserID variable and if it is not greater than zero, the user is bounced to a "You appear to have timed out, please log in again" page. I found that this would happen much sooner than sixty minutes (sometimes when submitting a form that reloads the same page). I disabled the response.redirect and output the contents of the session object, and found that although the sessionID value stayed, the values in all the variables in the collection would come up as zero for no apparent reason and with no predictability. I thought that perhaps the large number of session variables combined with a large number of users could mean that the server memory was getting stepped on by some other process. I haven't yet tried to implement a database solution because the problem is intermittent but if anyone discovers a way to fix this, I'd love to know about it. In the meantime, I'll look into the log files, and wether the storage in InProc.

Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Session Variables Randomly Disappeared Dmitriy .NET Framework 1.x 1 November 30th, 2006 01:24 AM
Session Variables in C# shikha09 C# 1 November 28th, 2006 10:38 AM
Session Variables Randomly Disappeared Dmitriy General .NET 0 November 20th, 2006 08:42 AM
Is it possible for me using session variables into see07 ASP.NET 1.x and 2.0 Application Design 4 March 9th, 2005 07:46 PM
session variables help face Classic ASP Databases 4 September 12th, 2003 03:57 PM



All times are GMT -4. The time now is 07:34 PM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.