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.
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!