1

There are reams of info out there about things causing InProc session to drop session objects, but that's not what's happening here. We're missing individual variables within stable InProc session objects, and are not sure whether they're not being written or being lost after a successful write. I've confirmed with WinDBG that the sessions are live and contain some, but not all, of the data written to them. 

Guid g = System.Guid.NewGuid();
this.Context.Session.Add(g.ToString(), result.ImageData);           
output.Write("<img src=\"display.aspx?id=" + g.ToString() + "\">");

This code is pretty straightforward, and it works flawlessly in Test. In Production, under heavy load, though, it fails ~1% of the time. If Mr Smith visits the site and attempts to display 4 pieces of image data, 2 of them might be saved in his session and two of them be lost.

The InProc session object for Mr. Smith exists. The traffic logs show he clicked 4 times, each with a different id param. But there are only 2 guids in his InProc session object, instead of 4. The 2 session objects we did capture do correspond to 2 of the id's shown in the traffic log (his 1st and 3rd clicks.) The traffic logs for his 2nd and 4th clicks, though, show a guid id that's not in his InProc session object.

Lines 1&3 of the above code obviously worked for those 2nd and 4th clicks, or he'd not have had the id in the URI for him to click. Line 2, however seems to have failed silently in some way. If any exception had been thrown, I'd expect we'd not ever have arrived at line 3. I can't see any way for the user to receive the guid id, but the session to fail to have it. The other possibility is line 2 worked successfully, but the variable later disappeared, how I cannot even imagine.

Can anyone think of anything else? Or maybe a suggestion for a way to repro an issue like this?

Details: ASP.NET v3.5 IIS 6 No Web Gardening We're running a web farm, but users constantly return to the same server. I'm researching now whether there's any way users might be slipping off to the other server.

codepoke
  • 1,272
  • 1
  • 22
  • 40
  • 1
    I would put moeny on people slipping off to the other server. Have seen something similar in the past, "sticky sessions" don't always do what they say on the tin! – Paul Hadfield Nov 12 '10 at 16:48
  • Given the high load, is it possible that you're running out of memory? Have you profiled this? Also, were you running a farm in development as well? – ScottE Nov 12 '10 at 19:09
  • Yep. Slip-sliding. I'm not a network guy and misunderstood the function of a Global Site Selector compared to a Content Switch. We live and learn. As for memory, I did dig deeply into that, so good suggestion. – codepoke Nov 15 '10 at 18:25

2 Answers2

0

Well, an easy way to figure out if the issue is because of Load balancer and sticky session is to stop using it completely and see if the issue reproduces.

If that is not possible, you can store the session out of process [state server] and check the sessions again. I worked at Microsoft Global Technical Support and have seen many cases where the sticky session just doesn't work!

http://aspalliance.com/1182

Rahul Soni
  • 4,941
  • 3
  • 35
  • 58
  • Yeah. Thanks for the ideas. We're looking at out of proc, but turning off the switch is not possible for the time being. – codepoke Nov 12 '10 at 18:21
  • It was indeed the user going to different farm members. We're using a Global Site Selector instead of our usual Content Switch routing solution. The GSS sends one or the other IP address in reply to a client's DNS query. The TTL on that DNS reply was 20 seconds, meaning the DNS reply expired way too soon to be practical. The short term solution is to extend the TTL. The long term solution is Out of Process Session Management. – codepoke Nov 12 '10 at 19:55
0

If possible in your situation, you can bypass the need for sticky sessions by having the same machine key on each server in your farm.

http://www.asp101.com/tips/index.asp?id=165

ScottE
  • 21,530
  • 18
  • 94
  • 131
  • Actually, the machineKey solution works with ViewState, not session state. InProc Session State is not machineKey encrypted, so it would have no effect in my situation. Our machineKeys have been in synch on all our farms for a long, long time now. – codepoke Nov 12 '10 at 19:52