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!
http://aspalliance.com/1182
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
Related
in an old ASP.NET Web Forms application, developed in Visual Studio 2010,
suddenly does not run anymore, and in the log file appears this message:
Session state has created a session id,
but cannot save it because the response was already flushed by the application.
No new deployment has been made, and no code modifications take place.
Until now I didn't find any solution to this.
What I have to check?
I state that the source code is no longer available, and therefore it would be very difficult to change the code and proceed with a new deployment.
Thanks in advance.
Luis
This would suggest that someone might be hitting the site and jumping directly to some URL (and thus code) that say does some response redirect to another page or some such.
Remember, when code behind runs, and say re-directs to another page, in most cases the running code for the current page is terminated, and that is normal behaviors.
However, the idea that you going to debug code and debug a web site when you don't have the code to debug? Gee, I don't see how that's going to work at all. As noted, if this just started, then it sounds like incoming requests are to pages that don't expect to be hit "first", but some pages that expect to be ONLY called from other pages in the site when some session() and imporant values are setup BEFORE such pages are to be hit.
It also not clear if the site is using sql based sessions, or just in-memory sessions. In memory can (and is) faster, but it also not particually relaible. Now, if you deployed to a new web server or new hosting, then often session errrors can now start to appear, and this is due to the MASSIVE HUGE LARGE DIFFERENT of using cloud based hosting vs that of older hosting soluions that run on a single server.
Clould computing is real utility computing, and thus when you host a web site on such systems, then in-memory session() cannot be used anymore, since multiple servers can and will be used to "dish out" web pages. Since more then one server might be used, then obvisouly in-memory sesson() can't work, since a few web pages might be served out by one server, and then a few more pages might be served out by another server. And using shared memory for a session is limited to ONE server, since multiplel servers don't and can't transfer their memory to other servers.
So, this suggests that you want to be sure that sql server based sessions are being used here - and for any kind of server farm, or any kind of system that does load balances between more then one server, then of course you HAVE to use sql server based sessions, since in memory can't work in that kind of environment.
The error could also be due to excessive server loads - often the session database is "locked" for a short period of time, and can thus often be a bottleneck. So, for say years you might not see a issue, but then as load and use of the web site increases, then this can become noticed where as in the past it was not. I suppose the database used for storing sessions could be checked, or looked at, since as you note, you don't have the ability to test + debug the code. I would REALLY but REALLY work towards solving and fixing this lack of source code for the web site, since without that, you have really no means to manage, maintain, and fix issues for that web site.
But, abrupt terminations of web pages? As noted, this could be a error triggered in code, and thus the page never finished what it was supposed to do. And as noted, perhaps a page that expects some session() values but does not have them as explained above could be the problem. It not clear if your errors also shows what URL this was occurring for.
While nothing seems to have changed - something obviously did.
Ultimate, you need to get that source code, or deal with the people + vendor that supplies the code for that site. If you don't have a vendor, and you don't have source code, you quite much attempting to work on a car that you cant even open the hood to check what's going on under that hood.
so, one suggestion here? Someone is hitting a page that expected some value(s) in session to exist. Often the simple solution is to shove ANY simple or dummy value into session so session REALLY does get created, and then when the page attempts to save the session(), there is one to save!!!
In other words, this error often occurs when session is attempted to be saved, but no sesison exists. For such pages, as noted, a simple tiny small code change of doing this session("zoozoo") = "my useless text" will fix this error. So, it sounds like session is being lost.
As noted, a error on a web page can also trigger a app-pool re-start. If app-pool re-starts, then session is lost (in memory session). Now, with session being lost, then any page that decides to terminate early AND ALSO having used session() will trigger this error.
So, this sounds like app-pool is being re-started and session is being lost. (you can google why app-pool restarts and for the many reasons). However, critical to this issue would be are you using sql based sessions, or in-memory (server) sessions? So, this sounds like some code is triggering a error, and with a error triggered, app-pool re-starts. And with app-pool being restarted, then in-memory session is blown away. And now, without ANY session at all, then attempts to save the session trigger the exact error message you see. (and this is why shoving a dummy value into the session allows and can fix some pages - since you can't save a "nothing" session, and if you do, then you get that exact error message.
but, as noted, you can't make these simple changes to code anyway, right?
But, first on this issue - are you using memory based sessions or not? And that feature can be setup and configured in IIS, and without changes to the code base. So, one quick fix might be to turn on sql server based sessions. It will cost web site performance (10%), but the increased reliability is more then worth the performance hit.
Another area to look at? Are AJAX calls being made to a page, and again without any previous session having been created? So, once again, we down to a change in end user behaviors, and possible those hitting a page first before having logged in, or done other things - and again one would see this error crop up.
Problem description
I have an ASP.NET app in which the users have different rights, and are logged in through Facebook. The app includes (among other things) filling out some forms. Some users have access to forms others don't. The forms can sometimes require some searching in books and/or on the internet before being able to submit them.
As such, we're having problems with session time-outs (it seemed), where users would be met with "Not authorized to see this page/form" after doing research somewhere else.
Attempted solutions
I've created a log function that logs the state of a handful of variables on strategic points in the application. I've pinpointed the problem to the fact that the Session variable "UserRole" is null when the problem occurs.
Relogging
The obvious solution is: "Have you tried relogging?" - which should reset the session and allow the user back to the form they want. On logout, I use
Session.Clear();
Session.RemoveAll();
and I create a new session with relevant variables (including UserRole) on login. This doesn't help, though.
Keeping session alive
One way to do it is just increase the standard 20-minute Session length to an arbitrary, higher number (say 2 hours). Although that could be viable during beta (there are only around 5 users right now), it is not a viable solution in the long haul as the server would have to keep the Session objects from many users for longer time, exponentially increasing server demands.
Instead, I created a 'dummy' .ashx handler "RefreshSession.ashx", that can recieve a POST request and return "200" statuscode. I then created a jQuery function in the shared part of the app (that all the pages use) that calls this handler every 10 minutes in order to refresh the session as long as the tab is open in the browser. I've checked the network traffic, and it works as intended, calling the handler even if the window is minimized or the user is viewing another tab. This did not solve the problem either.
A caveat
When one of the users encounter the problem, they call me or my programming partner up. Of course, we go and see if we get the same issue. We all have the same (admin) rights. The 'funny' thing is that we see the exact same error on the same subpage - even if we haven't had any contact with the application for days.
The problem will 'fix itself' (i.e. let users with proper role back on the subpage) after a while, but not even republishing the app to the server will reset it manually.
Therefore, it seems to not be a simpel session error as supposed from the "UserRole" session variable being null after 15-20 minutes of inactivity. It seems to be saved somewhere internally in the server state.
My problem is, that I now have no idea where to look and how to progress. I was hoping that someone here might have an idea for a solution, or at least be able to point me in the right direction? :-)
Thank you all for your time, it is much appreciated.
Based on MaCron's comment to the question, we decided to keep the information in the user's cookies instead of the session variables. Everything seemed to point to us having exactly that issue, and deadlines being deadlines and with me not being able to figure out how to disable the synchronization of worker processes, this seemed to be a feasible and comparatively easy fix.
I have a simple scenario. in one page of asp.net, I store a some values in session like
session("var") = "some string"
or
session("var1") = object of generic list of string
and then use response.redirect to goto another page.
on other page it shows things fine, but when we press a button to do an action on it, session gets null.
Remember, it doesn't always happen. Just sometimes it does so and other times it works fine. We do this practice a lot to move some values from page to page (by storing them into session and goto other page). We have very big application and all works fine, but from some days, have been having this issue on some sites with some users. Once again, it doesn't always happen. 99% it works fine but few times, we have this issue where session variable is no longer available.
Is there any way to know what is going wrong and where? We do store some other variables in the session as well, they seems fine at that time. only some of the session variables lose their values.
From my research, it seems people blames on the IIS worker process restart or Application Pool recycle. But I believe in such case all the session variables in the application must be voided, not selected few. Right?
also, is there any way to know in code if the pool or worker process was restarted?
thanks
Sameers
Perhaps you're passing domain boundaries. Session is identified by a client cookie, which are usually stored on a per-domain basis. So, for example, a redirect from www.whatever.com to client.whatever.com will cause you to lose the session ID, which will appear to you as "voiding the session". So, be careful about sub-domains too. Going from whatever.com to www.whatever.com is fine, but the other way round, nope.
And yes, unless you're on a web farm IIS, restarting the worker process will kill all the sessions. Unless you store them in a database or something.
I'm working on a web application that currently uses a Session to hold the userid and privileges. This is causing a problem for me because the client ip address changes normally every 5 minutes, sometimes faster, so the sessions are lost.
My current work around is to encrypt a string the will auto-login when the session dies, but it still causes issues because forms will not be submitted if the auto-login process has to be run.
I can post some code, but I feel that I'm way off base with my current method of attack. Can I please get some suggestions?
Thank you!
The webapp is for about 10 users and if possible, I'd like it to never timeout so that if they are looking at a page for 4 days and come back to it, they can press submit and it submits.
I'm not sure why you're losing session after 5 minutes, or why it appears to be correlated with client IP address changes (is this an intranet app? Does something else happen on 5 minute intervals?).
The following web.config setting should create sessions that last for 6 months, and will survive application pool recycles:
<sessionState mode="StateServer" timeout="262800"
stateConnectionString="tcpip=127.0.0.1:42424"/>
Of course, you'll have to have the state server running on your machine, and everything stored in the session will need to be serializable.
As Jarrett points out, it's rather odd to want to keep sessions alive for so long with no activity, and I wouldn't recommend it if there was going to be a significant number of users, but if it really is 10 and only 10 users, it's probably okay.
If you need the page to stay valid for four days, don't use Session and don't use Viewstate. You can store data in cookies, on the page in hidden input fields and in the URL querystring. Nothing else is going to be reliable over that span of time. If you are storing sensitive or security dependent information, do it responsibly, that is probably its own question.
Is it possible for ASP.NET to mix up which user is associated with which session variable on the server? Are session variables immutably tied to the original user that created them across time, space & dimension?
To answer your original question: Sessions are keyed to an id that is placed in a cookie. This id is generated using some random number crypto routines. It is not guaranteed to be unique but it is highly unlikely that it will ever be duplicated in the span of the life of a session. Even if your sessions run for full work days. It would probably take years for a really popular site to even generate a duplicate key (No stats or facts to back that up).
Having said all that it doesn't appear that your problem is with session values getting mixed up. The first thing that I would start to look at is connection pooling. ADO pools connections by default but if you request a connection with a username/password that is not in the pool it should give you a new connection. Hint that may be a performance bottleneck in the future if your site is very large. It has been a while since I worked with SQL Server, in Oracle there is a call that can be made to switch the identity of the user. I would be surprised if there was no equivalent in SQL Server. You might try connecting to your DB with a generic username/password and then executing that identity switch call before you hand back the connection to the rest of your code.
It depends on your session provider, if you have overriden the session key generation in a way that is no longer unique, then multiple users may be accessing the same session.
What behavior are you seeing? And are you sure there's no static in play with the variables you are talking about?
while anything is possible. . . .
No, unless you are storing session state in sql server or some other out of process storage and then messing with it. . .
The session is bound to a user cookie, the chances of that messing up in a normal scenario is very unlikely, however there could be issues if using distributed session state.
It's not possible. Sessions are tied to the creator.
Do you want to mix up, or do you have a case when it looks like mixed up?
More information:
I've got an app that takes the userid/password from the login page and stores it in a session variable. I plop it into my connection string for making calls to SQL Server.
When a table gets updated, we're using 'system_user' in the database to identify the 'last updated by' user. We're seeing some odd behavior in which the user we're expecting to be listed is incorrect, and it's showing someone else.
Can you pop in the debugger and see if the correct value is indeed being passed on that connection string? It would quickly help you idenfity which side the problem is on.
Also make sure that none of the connection code has static properties for connection or user, or one user may have their connection replaced with that of the most recent user before the update fires off.
My guess is that you're re-using a static field on a class to hold the connection string. Those static fields are re-used across multiple IIS requests so you're probably only ever seeing the most recently logged in user in the 'last updated by'.
BTW, unless you have a REALLY good reason for doing so then you shouldn't be connecting to the DB like this. You're preventing yourself from using connection pooling which is going to hurt performance under high loads.