Asp.net Session Data Loss

Question

I spoke about this in a previous question, but I have since narrowed down the issue to make it possible to be answered. First, some background.

I have an ASP.net website that functions normally on the local server, but when it's on the live server and accessed externally, it has some session data issues that make occasionally throw errors. The first issue turned out to be an problem with IE9. The session variable just wouldn't persist after it reached the second page and hit the stored procedure. I fixed this by foring the page to run in IE7 mode with -

This still occurs on some browsers (specifically it occurs -once- with firefox) but I created a loop that forces it back to the menu page when the session variable is blank so it just appears as the page didn't load and the "open" button can be pressed again.

However, the new problem happens when I attempt to save the data on a form. It passes a few session variables in to the stored procedure interface (like staff ID and such) and what appears to happen is that it times out. However, all of the timeouts for the session set in webconfig and IIS are extremely high numbers (many hours) and the worker processes are set to never expire or recycle. Also, it happens even after a minute or two so it can't be the timeout hitting. It's just like it randomly loses the session values. The weird thing is that if you go back and save again - performing the same actions with the same data - it tends to work. Sometimes it takes a few iterations of this but ultimately it will work.

The strange thing is also that it tends to randomly lose pieces of the viewstate - such as field values - but that might be unrelated and have more to do with the fields that are filled automatically at load. But I thought I'd include that in case it offers and information as to why it might be doing this.

I'm considering a workaround by dumping the session variables in to viewstate variables as soon as the page loads, but I'd really like to address the problem directly so I don't have to deal with it in the future when I can't do something like that. Is there some poriton of IIS (It is IIS 6 by the way) that could be the culprit? Are session variables just known for dying when being thrown around a lot? I can't say I know a great deal about server set up but I've learned a lot from this situation and beating this will be a wonderful victory for my morale. Thank you for reading and sorry it' so long!

Answer 1

Please check if this server is load balanced.

In either case, check this article out. http://aspalliance.com/1182_Troubleshooting_Session_Related_Issues_in_ASPNET

Hope this helps.

Answer 2

OK!

After reading your post and thinking about it, I think most likely cause of the problem is the dodgy ISA Server . Proxies tend to mess around with the HTTP content, decide to change the headers and the like. As you have mentioned, this only happens if it is accessed externally. This is the hallmark of man in the middle issues.

Now to prove, you have to compare the headers sent externally and headers you receive. This is a bit difficult but not impossible at all. All you need is to log all the headers (requests) on the server side while you do the same from the client's machine (perhaps using fiddler).

This should be able to prove the dodgy proxy - we have a similar issue in our company.

Answer 3

Well I did a couple things and it is working now, but I didn't test which was the actual solution and none of them, the best of my understanding, should have actually fixed the issue. First of all, at some point I increased the available worker processes to three from one, which I thought would mean would allow the user to run multiple processes on the server if necessary, but it turns out that is only necessary for server farms. So I set that back to one. It was one before when this issue was occuring and I was basically just expirmenting to see what would fix it.

The second thing I did was add in a simple if statement (if the session variable is blank) in one private sub that contains an the interface for a stored procedure that sends a session variable. I thought this would be a workaround, but then I looked at my old error logs and it wasn't even the stored procedure interface that was throwing the error. I have no idea why it would have fixed the issue at all.

I also set up some PerfLogs like on that page that Rahul linked me to to try and monitor what's going on with the sessions.

Now aside from the odd fact that something in there amongst those attempts (along with whatever other minor things I did) actually fixed the problem, there's the fact that it was never happening locally to begin with. I'm not really sure what happened, but it's working now and I'm not going to dig too deep in to it again since I have a lot of projects to attend to. In my opinion it's most likely an issue with the ISA servers that may arise in the future, but my lack of knowledge about their settings limited me from really getting in there and looking around for myself. When I asked about it, I was told that it should allow for everything I need to send through it to go through it. Regardless, I'm just happy to be able to move on and get this working. Hope all of this helps some people in a similar situation! Thanks for all of the help everyone!

Answer 4

I actually found the real solution this time around. It still doesn't make a lot of sense but I thought I'd bring it here just for everyone to see. It turns out, one of the dates that was being pulled from a table was being stored in the session variable as a blank (even though it shouldn't have been) and then somehow, even though there was an if statement that should have prevented it, it tried to convert the blank string of the session to a date. Certainly strange. It was as if the session had a value when reaching the if statement and then after it checked it against the criteria, it changed it to a blank string and threw the error.

So it turns out it wasn't really a session issue, just a strange date issue. It was only occuring with one person and one particular date from the table. I fixed it by simply putting a try-catch around it. Everything has been working fine for that individual since then. Thanks again for the help everyone!