1st post on stackoverflow, hope to have great feedback :)
I'm currently trying to load balance our web site. We have set up a 2 cluster NLB on windows server 2003 with IIS 6.
While testing the setup, I found that sometimes, our session is lost. A day and a half later, here's the result:
Yes, our machine.config both have the same encryption/decryption key.
Yes, the id in iis metabase.xml are the same for both machine. Actually, the entire file are the same, except for "AdminACL".
Both web application are set with "StateServer" and both pointing at the same machine.
From that point, searching on google gives less information and possible solutions.
From what I know, there's no particular pattern that cause this problem. It just happen once in a while.
While trying to find the problem, I've seen that a request sent the asp session id cookie to the server, but the server didn't map it to the user session.
So the request number x was sent from the client, with the cookie, session was mapped, and everything went smoothly.
The request number x+1 was sent from the client, with the cookie, but session was not found.
Both request were made on the same machine in the NLB.
Here's a snippet of the asp trace.axd:
1st request:
Request Details
Session Id: j2ffvy45updpc52uhw1mbg55 Request Type: GET
Time of Request: 11/26/2008 2:58:06 PM Status Code: 200
Request Encoding: Unicode (UTF-8) Response Encoding: Unicode (UTF-8)
Request Cookies Collection
Name Value Size
ASP.NET_SessionId j2ffvy45updpc52uhw1mbg55 42
AID 22 9
Response Cookies Collection
Name Value Size
Headers Collection
Name Value
Cookie ASP.NET_SessionId=j2ffvy45updpc52uhw1mbg55; AID=22
2nd Request:
Request Details
Session Id: Request Type: POST
Time of Request: 11/26/2008 2:58:08 PM Status Code:
Request Encoding: Unicode (UTF-8) Response Encoding:
Request Cookies Collection
Name Value Size
Response Cookies Collection
Name Value Size
Headers Collection
Name Value
Cookie ASP.NET_SessionId=j2ffvy45updpc52uhw1mbg55; AID=22
As you can see in the 2nd request, the cookie is sent from the client, but asp seems to never add the cookies in it's "Request Cookies Collection". I think that's why it doesn't find the session.
So why the cookie is not mapped to the session? Is that the problem? Is the problem elsewhere?
Feel free to ask any clarifications.
Thank you all for your feedback.
JF
I finally found the answer to my problem. It's origin are within the application code (like 99% of a programmer's 3rd party tools 'bugs'). I decided to post it anyway in case someone is in a similar scenario.
This code was part of WebServiceRequester class. The web service requester class was instanciated when session was created and it is saved in session. During creation, we initalizate the member 'm_webServiceURL', and this member is saved in session after. At which value was this member initialize was depending on a setting on the local machine.
The important part is the following:
WebServiceRequester class contains a WebService objects.
WebService objects can't be saved in session, they are not serializable in asp. The property had the [NonSerialized] attribute on it. So everytime we accessed the 'WebService' property of the object for the first during a page life cycle, we had to create a new one, and assigning ot it the url 'm_webServiceURL' which was saved in session.
So you see, new webservice object, on possibly a different machine, meaning a different setting on each machine.
so here's what happened:
box 29 was set to access Web Service at localhost
box 30 was set to access Web Service as 192.168.253.29.
Technically, they are both set on the same machine. But here's a scenario:
login on box 29. m_webServiceURL is set to localhost in session.
[some request on box 29 here]
NLB balancing bring us on box 30.
box 30 loads it's session, create a new webservice obect with localhost as the web service address.
box 30 made the request to the wrong web service leading to a Session Expired exception.
One of the problem during the debug, was that the local communication were not recorded with the network monitor.
What lead me on the trace, was that we never had an exception logged on the box 29 log trace, as it should have.
Thanks for you suggestions everyone, it was really appreciated.
Have a good day.
JF
Not strictly an answer to your question, but have you tried it using a sql server based session store? (Search on MSDN for the permanent script rather than the temp script that's provided with asp.net)
I've heard "bad things" about the executable session service, and consequently have not used it. Never had any problems web farming with the sql server based solution though.
Sorry it's not strictly an answer to your problem, but it should either (a) fix it, or (b) narrow it down significantly.
Well, if you're using visual studio, you could at least test it with the MSDE (the cut down version of SQL Server that comes with Visual Studio)...
It might help rule out state server problems...
Using the database approach has its own issues. I think you should be able to use your preferred approach.
Perhaps this session troubleshooting article would help?
Or "Troubleshooting Session Related Issues in ASP.NET"
Or "Troubleshooting Expired ASP.NET Session State and Your Options"
I'll be lame and re-iterate the proposal of MS SQL Server. Install SQL Server Express which is completeley free including for commercial use and it has only these 3 drawbacks which shouldn't be a problem for you in this stage :
Max 4GB size database
Max 1 CPU Core used
Max 1GB RAM used
A few points to take into consideration:
What's the load on your website? State Server has the tendency to crash when facing a large number of concurrent hits. We're only using it in scenarios where we have a really small number of users (in the 10's, mostly backend systems). Whenever we tried using it in production for sites serving 1000's of users daily, it would crash leading to loss of session data.
On one of the production environments we manage, we're using MSSQL 2005 Express to manage the sessions, the site has 10K+ users a day and 200K+ pages a day. This is a recommended approach in case session is a must and tightly coupled into your application.
If you're about to user MSSQL Express as your state DB, remember that it doesn't come with SQL Server Agent meaning there's no tasks scheduler running in the background and cleaning your expired sessions. I'd recommend finding a scheduler and running the clean expired sessions stored procedure periodically.
Good luck
Instead of messing around with SQL, send your tests directly into one of your IIS nodes to see if you still get the same issue. I'm sure if your only doing a small number of tests StateServer won't be the issue.
Try setting the domain name of the asp.net_sessionid through code to ".yourdomain.com".
By default the ASP.net_SessionID cookie domain name is set to the full application path. So, this may be one of the reason why the cookie is not travelling.
E.g.
Request.Cookies["ASP.NET_SessionId"].Domain = ".yourdomain.com".
Remember the first "." is important in the domain name.
You could do this in the HttpModule in the AcquireRequestState event.
Related
I have the following use scenario: User logs in to ASP.NET application; and at some point makes a connection to remote TCP/IP server. The server's response may come after significant delay (say, a few hours). Imagine that the user submits a batch job, and the job may be running for a long time. So, the user may close the browser, get some coffee and come back to see the results later.
However, if client closes the connection, the server will never return the results. So, keeping Socket info in Application object won't work - once user closes the browser, it goes away.
Is there any other way to persist this open socket while IIS is up? Also, if the second user logs in, I would prefer to use the same connection. Finally, I realize that the solution is brittle, and it may occasionally break. It's OK.
Remote server is 20-year old mainframe application; so no chance for changes there. And as long as the user doesn't log out - everything is working fine now. Everything is on the LAN, so there are no routing issues to complicate the situation.
The contents of the application dictionary are not lost when a user logs out. Your scheme will work (in a brittle way, but you say that's ok).
Note, that worker processes can exit for many reasons, so expect to be killed at arbitrary points in time.
you have several options for persisting session-state: MSDN - Session-State Modes
inproc mode: you disconnect, state is lost. if you use cookies, and
store info/data somewhere on the backend, then you can map the GUID
to the data, regardless of session. or use application-state.
stateserver: persisted across disconnects and application restarts,
but not across iis/pool/server restarts, unless you use another
server, or cookie/auth. can be problematic sometimes.
sqlserver: as the name implies, uses a specially formatted db/table structure to persist state data across all sorts of scenarios.
custom/off: allows you to build your own provider, or turns it off completely.
here's the cookie method, by far the simplest (you have to generate a GUID, then store it in the cookie and application state or a backend DB): MSDN - Maintaining Session State with Cookies
you can persist cookies on the user's client. then, on server
reboot/client disconnect/any other scenario just pull the GUID from
app/session state or from a backend DB, which will also store the data
for the reports/output.
also, as a caution: even though cookies can be used to auth a user to an account/db record via GUID, it is considered insecure for all other purposes except unindentifiable information, such as: view shopping cart, simple reports, status, etc...
oh, and the stuff on IIS session timeouts (20 mins by default): MSDN - Configure Session Time-out (IIS 7) and MSDN - Configure Idle Time-out Settings for an Application Pool (IIS 7)
completely forgot to add the links on: ASP.NET Application State Overview, ASP.NET Session State Overview, but storing large amounts of data on a busy server in application state is not recommended. oh yea, and MSDN - Caching Application Data
I am currently debugging some issue about this.
We have a ASP.NET web application and I am debugging on Cassini. When I tried to use IE and send out the request to the server, some time (e.g. in about 20minutes) is needed to process and then send out the response.
In case of multi-tab IE, I tried to send out the requests in different tab at about the same time to the same server but the response is handled only after the one of the response is sent out.
If a new instance of IE is started and the requests are sent out in these different instances, the server can process and send out the response almost simultaneously. After doing some research I found that IIS express may solve my problem, but I cannot. Anyone has experienced similar problem or have I missed out some really important things to check with first?
Thank you for your help.
This is primarily due to ASP.net's session state variable and the fact that only one request at a time may have R/W access to a particular session (as determined by the SessionID cookie).
Any additional requests requiring any form of session access (since Read/Write is the default) will be blocked until the previous request has been completed.
Based on the following links:
http://johnculviner.com/asp-net-concurrent-ajax-requests-and-session-state-blocking/
https://msdn.microsoft.com/en-us/library/ms178581.aspx?f=255&MSPPError=-2147217396
I think that you miss the point that the session is lock all request leaving only one per time to run.
Read about that and why:
Replacing ASP.Net's session entirely
Also : Web app blocked while processing another web app on sharing same session
The reason is that Sessions in ASP.NET are not thread safe. Therefore ASP.NET serializes access to requests from the same session.
If you have a multi-tab IE then your tabs share one session. The first request is executed right off and the other ones are queued. If you have different instances then each of them creates a new session and therefore the request are executed in parallel.
We have ASP.NET cookieless sessions (inproc), so URL contains the session id, i.e. S(dfasfdafasdfasfa)
We also have several clients going through proxy servers where it appears like our web server doesn't recognize the session id and without the session data they can't continue. I've tested our sites on open proxies and they work fine. But there is something going on with this particular client proxy server that causes this behavior.
I've examined package captures for the success and fail cases (provided by the client) and the raw HTML getting transmitted, including headers, is the same. The proxy server does not appear to be caching URLs because the correct session id is coming down.
So my thought is that IIS7 is using something in addition to the session id in the URL to determine a unique client. Perhaps something at the TCP/IP level? Rather than just App(http) level. Is this on track? Does anyone know the answer to this?
Unfortunately without being able to recreate this scenario locally I'm racking my brain hard.
Log the Request Url, SessionId and IsNewSesssion.... that should tell you where the problem lies.
I doubt you would see a valid session presented in the Url but not reflected in SessionId. If you see the value you expect reflected in SessionId but IsNewSession is true across multiple requests, then it's an app recycle issue.
My forms are losing session variables on shared hosting very quickly (webhost4life), and I think I want to replace them with cookies. Does the following look reasonable for tracking an ID from form to form:
if(Request.Cookies["currentForm"] == null)
return;
projectID = new Guid(Request.Cookies["currentForm"]["selectedProjectID"]);
Response.Cookies["currentForm"]["selectedProjectID"] = Request.Cookies["currentForm"]["selectedProjectID"];
Note that I am setting the Response cookie in all the forms after I read the Request cookie. Is this necessary? Do the Request cookies copy to the Response automatically?
I'm setting no properties on the cookies and create them this way:
Response.Cookies["currentForm"]["selectedProjectID"] = someGuid.ToString();
The intention is that these are temporary header cookies, not persisted on the client any longer than the browser session. I ask this since I don't often write websites.
Before changing any code, I would investigate why session variables are disappearing.
Perhaps it is as simple as changing the timeout setting in the web.config?
Here's a list of the session state settings in the config file: Session Element on MSDN
====================================================
Oh yeah, one other thing to try in relation to your comment:
If my memory serves me, we had some issues in the past when deploying to a web garden/farm where multiple web sites on the same server would "clash". To get round this we explicitly names the cookie as so:
<authentication mode="Forms" >
<forms loginUrl="your-login-page.aspx"
cookieless="AutoDetect"
name=".A-NAME-WHICH-IS-UNIQUE" />
</authentication>
Name: Optional attribute.
Specifies the HTTP cookie to use for authentication. If multiple applications are running on a single server and each application requires a unique cookie, you must configure the cookie name in each Web.config file for each application.
The default is ".ASPXAUTH".
From here link text
No you do not have to keep resetting the cookie in the response.
Once set that cookie will continue to be sent with each subsquent request.
However I agree with Dominic you should first determine the reason you are unable to maintain the session in the first place.
Some reasons are:-
The host is using a web garden or a load balancer that does not support session affiliation
There is an aggressive setting for session timeout on the host
The host has a problem and is recycling the application pool frequently
Your client has overly tight cookie settings and is rejecting all cookies (however that would mean your alternative solution wouldn't work either)
Application logic may be faulty causing Session.Abandon or Session.Clear when it ought not.
In answer to your question about copying the cookie from the request to the response, no this is not necessary.
When the cookie is created it can persist for as long as you require.
If it is just needed for the duration of the session then do not set anything against the Expires property. In this case the cookie will be held in the browser memory and served up with each request to you website until the browser is closed.
If it is to persist between sessions the set the appropriate DateTime value against the Expires property. In this case the cookie is written as a file on the client machine and continue to be served up with each request to your website until it's exiry date is reached or it is deleted.
Of course, be aware clients can disble cookies in their browser.
I do agree with previous answer, that you should investigate the sessions timing out first!
But regarding cookies:
Request cookies are the cookies sent from the client to the server and Response cookies are the ones sent from server, telling the client to save them locally and attach them to the next, and all upcoming until the cookie is outdated, requests to the server.
Cookies have a limit on size and because of their behavior will create an overhead on data sent between server and client on requests, and can of course also be disabled on client side as well.
I would suspect that the reason you might be loosing session variables is that your application is running in a web garden. This means two or more processes are running your application.
In your web.config there should be sessionState tag. If mode="InProc" then try setting mode="StateServer". This will cause all the processeses hosting your application to use the session state server to store the session state elements. Also check the timeout as was mentioned previously.
The research I've done into cookies suggests they would not be a desirable alternative to session variables. Browsers enforce arbitrary limits on the number of cookies that can exist at any one time as well as the number per site. They are also prone to being dropped randomly.
You can enable cookieless sessions. There are some potential issues but it might work for your site.
I was a webhost4life customer up until two months ago, the issue I was experiencing was the application pool being recycled frequently - probably because the host had some kind of problem. In the end I moved to a VPS and never looked back (not a webhost4life VPS either).
For Sharing hosting the best approach is to use SQL Session State.
It's a little bit slower but much more reliable.
I had the same problems back in the days and my Memory Sessions were always getting erased, this happends because someone on the same hosting environment didn't know how to accomplish stings and IIS just reset the Application Pool, or it could even do by Auto Refresh the AppPool from the Hosting point of View (so no website will hang).
Since I started to use SQL State ... I just must say WOW!
you have total control in everything, even set the timeout (Memory Sessions are set by the machine config and no matter what you set in code or web config you will never override that setting)
and you gain something new, if you change the code, you users will not need to left the website to re.login again as they will continue from their existing session.
Setting it up it's fairly easy and you have a ton of examples on how to accomplish such behavior.
no matter what you do, DO NOT GO to cookies as they are not reliable!
You might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It can automatically switch to the session whenever the cookie is unavailable. It also has a server side implementation of the cookie whereby all cookies are stored on the server and asp.net authentification can be used to identify the user.
I am seeing a very strange problem on one of my production boxes. We have an application hosted in IIS 6 on a single machine with an apache web server in front of it. My application is using ASP.NET Membership for authentication and relies on session state. I am seeing a problem right now where some server requests will hit a null exception when trying to access any session variables, but if the request is retried, the page hits no exceptions and behaves properly.
I believe this has something to do with the Session ID cookie either getting corrupted or lost on the request, but I have no idea what could cause that. The reason I believe this is because it seems like ASP.NET is not seeing the cookie and creating a new session, which would explain why the variables are null. When it gets the exception, it cannot write the new SessionID cookie back to the client, so the client still maintains the original SessionID. Then when the next request is sent, the original SessionID cookie is used, which now ASP.NET finds and is able to retrieve the session state. This is pure speculation, but seems to fit the symptoms.
Also this site is using no other cookies other then the ones required by ASP.NET Membership and ASP.NET Session, so I am well under the cookie limit for IE. The site has been functioning properly for about 8 months and this issue just popped up recently. I have tried IIS resets and actually rebooting the machine, but nothing has seemed to help the problem.
Updates:
Here are some clarifications that were asked for.
1.)Our Apache server is the only thing exposed to the internet. All requests occur over HTTPS to this box. The Apache box then forwards all request past over HTTP to our application server. This is being done for security reasons. We have looked to see if Apache might have been the issue, but there seems to be no error in the Apache logs.
2.)The null exception is occurring when trying to access an object stored in session that the application expects to be there as opposed to the exception happening with the actual session object itself.
We have found the root of the issue. It looks like the IIS meta-base got corrupted on our app server. The best way to fix this issue is to do a clean install of IIS, but because of business constraints, this is not an option for us. So another solution is to actually just create a new App Pool for the application to run under. According to some people with more IIS expertise than myself, this will fix the problem in the short term, but it is very likely that the same thing will happen to this App Pool. So we are required to create new App Pools if this starts occurring again.