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.
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.
I had to update an old ASP+COM application for a customer when they went from Windows 2003 to 2008R2. The process, while not 100% painless, was sucessful but one problem remains: the application seems to randomly lose the session state or, at least, the session variable where I save the session's COM object.
Basically, the app works like this:
Login form page -> login page (object is created there and saved in Session("MyObject"), user credentials are checked -> First actual application page (Session("MyObject") is checked at the top of the code).
The Second redirect only happens if the credentials are correct but the object is always created.
However, users are reporting that they are frequently being redirected to the logon form page after entering their credentials.
After some investigation, it seems that the application properly goes through the login page, creates and instance of the COM object and redirect to the first application page. And there, the session variable is empty again and so the user is sent back to the login form.
What's more is that it is by far not systematic: the problem happens rather frequently but definitely not all the time. When it starts, users have to log on 2 or 3 times before they can get through. If the application is recycled, it usually solves the issue for some times although this isn't systematic and this isn't even always necessary.
Anyone has any idea what could be going on here ?
Edit: some extra info:
ASP session handling is active
In no part of the code are errors being silently suppressed. They will go to a log file if they happen somewhere the COM object can catch them or the user otherwise.
No error can be seen in the COM object log file, in the IIS log or in the server's event log.
Tracing the process activity with ProcMon didn't turn up anything special.
Looking at the COM object log file, I clearly see the COM object instance being created, the "LoginUser" method being called from the login page and returning successfully and then the first application page being called and the check for the existence of the object stored in the session failing.
There is a single web server, no server farm.
I did have an asp website that did exactly the same thing in the past. You need to check the log files and see if this application or website is running on it's own dedicated application pool and that the application pool is not being auto recycled due to bad code. If the session is being created then dropped, then pass the initital session value to another session - say Session("MyObject2") and check for that in the main page. If the users are still getting logged off then I am sure that the application pool is being recycled due to too many failures such as a redirect infinite loop or something else.
Edit: One more thing. I used to see such errors a lot when using ASP with MS Access and could never figure that out.
As a debugging exercise, I'd be tempted to log info from the ASP Session events including the session OnStart, OnEnd and abandon. Maybe try and get as much info from the request and then work out a given lifecycle/page flow for sessions and then determine if there is anything in common that occurs when the session is either ended or abandoned.
Also, while looking up the Session_OnEnd event, I came across an article that suggests it behaves weirdly in IIS 7.0 See http://blogs.iis.net/lprete/archive/2009/01/04/session-onend-classic-asp-and-iis-7-0.aspx just in case this might be of use.
Good luck.
I'm a little confused about the life cycle of the session in ASP.NET, here is my test case.
A user logs in, I save some info to a session variable (e.g. Session["bob"]="bob") then I do an "IIS reset". The user is still logged in, but the session data is null (e.g Session["bob"].ToString() throws a NullReferenceException.
I expected the session data to still be around. Is there something I can do, other than log out the user? I expected the session data to be around as long as the user is still logged in.
Any good links so I grok what's going on, as well as any help with the actual issue is greatly appreciated. I tried to Google this, but wasn't able to frame the question in a way to get what I wanted.
The behavior you are seeing - where the Session contents do not survive an IIS reset event - is due to where the Session values are stored. By default these values are stored within the memory of the ASP.NET "Worker Process", which is the program which runs your ASP.NET web site.
When you perform an "IIS reset" you shut down the entire IIS server, including the ASP.NET Worker Process. This means that the contents of the Session are removed from memory. Your user still appears to be logged in because that is controlled by the cookie stored in their browser. If the cookie is still valid, the login is.
If you wish your Session state to survive an IIS reset (or anything else which causes the ASP.NET worker process to restart) you'll need to store your Session objects in another place. This is fully supported by ASP.NET by using different Session storage "Modes". Read about those in the MSDN article "Session-State Modes".
For a general overview of the Session, check out the "ASP.NET Session State Overview" article on MSDN.
yah its right but some time its happen then session no remove properly at that time
you have to check session like
If Session("username") = nothing then
Response.redirect("~/default.aspx")
End if
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
Does anyone know what this value is for?
If it is set to 1, then it seems that you can only have one request going to the server at once. For example, we have a classic ASP file that loads fine, but also has images in it (which come from the same script on the server). The page will load, but the images will never load in... the page just spins forever.
Upping the MaxProcesses value in IIS7 fixes this, but then each time a new process is spawned we then run into problems with session values not persisting as well as long page loads that we don't get when MaxProcesses is set to 1.
There is probably some other setting I don't know about that works in tandem with this.
See this question for the answer (server side debugging was on).
Gets or sets the number of worker processes associated with the application pool. Default = 1; A value other than 1 indicates a Web garden. In this scenario, if you want to preserve your session you need to choose an out of proc method for sessions (for example using SQL Server).