what could the cause behind dropping of authentication cookie (.ASPXAUTH) intermittently in an MVC3 app?
I checked the size of cookie which seems to be around 2kB.
It flows without any issues during login and performing few actions in site. but after performing one specific action (where I am returning a pdf file from server and cookie in untouched there) it drops for a very few users.
Could there be any other reason behind user being logged out of system after certain action?
I just have got info that cookie can be dropped if your applcation is being recycled by the server. There are three conditions that would cause your application pool to be recycled by the server. 1. Over CPU usage. 2. Over memory usage. 3. No http calls for 20 minutes.
Related
Setting up a couple new Coldfusion 2018 servers and will be using clustering for the first time and have run into some problems.
I am having trouble with session replication. Basically, session variables appear to be replicated between nodes in a cluster but are killed after a short while at random.
A little setup info:
2 web servers (Windows Server 2012) behind load balancers
On each web server sits a Coldfusion cluster consisting of 2 local instances (still unclear if this is useful or not - will ask in separate question) and 2 remote instances (the remotes reference the local instances of each opposite server)
For simplicity, currently just testing on a single server with local Coldfusion instances - leaving the remotes out of the equation until I can get things working reliably locally
Using J2EE session variables
Coldfusion session timeout set to 2 hours
In each Coldfusion instance, channelSendOptions is set to "6"
Here is what I did/experienced:
We have a web application that requires login and stores user information in the session upon login.
I made a small modification to the web app to show me which cluster instance has serviced my current request.
After setting up the cluster, I started the web application and logged in, noting the instance which displayed the login page.
Upon logging in, I was immediately returned to the login screen (app checks for user info in session and redirects to login if not found)
Debugging revealed that I was actually being logged in but after redirecting to some new page after login the user info would be gone from session.
Multiple login attempts in a row (same credentials, just tried over and over again and again) revealed that sometimes login would proceed just fine and I would get into the app. However, if I refreshed the page or went to another page, the session would be lost very soon but at random (within a few page refreshes).
In an attempt to simplify the problem to try and figure out what is going on, I created a simple .cfm that bypasses all the login stuff and does one thing: adds a simple string value to session and then dumps the session and instance name.
** I ran the script once, noted which instance was being used and that session contained my value.
** I then edited the script so it no longer set the session value.
** I then hit refresh over and over so I could confirm:
That requests were being serviced by both instances in cluster
That as I flip-flopped between instances, the session value was available all the time.
Again, the replication would work and for several refreshes I could see my session variable available on each instance...until it wasn't. After a random number of refreshes/seconds (between 2 - 10 refreshes say) the value would disappear.
I am at a loss to explain why this is happening. We considered using Redis as a session store to see if it helped but frankly, our team has no experience with it, it is clunky to get working in Windows and we really don't want any more moving pieces in our infrastructure if we can help it.
Any insight on what is occurring as well as advice for how to peer behind the scenes as it were and see what is going on with session replication would be greatly appreciated.
Thanks
Adding some code and screenshots. The screenshots show the state of session after each page refresh and which instance is currently serving the page. The last two images represent refreshes 11 and 13 - the session variable was lost in 11 and I went to 13 so that we can see that the variable was lost on the other instance as well. Also a couple pictures of cluster/session setup.
Following is the simple test script. The first line is un-commented on first run to create the session variable and commented out for each subsequent run.
<!--- <cfset Session.svar="cake!"> --->
<cfdump var="#Session#" />
<cfscript>
hostaddress = createObject("java", "java.net.InetAddress").localhost.getHostAddress();
</cfscript>
<cfoutput>
<h3>
Instance: #createobject("component","CFIDE.adminapi.runtime").getinstancename()#
</h3>
</cfoutput>
We are having a problem with regards to All Session Variables being deleted at random times.
This happens without calling Session.Abort(); or Session.Clear(); IIS is also not recycled and NO App_Code, Bin, Global.asax or Web.config changes are made when this happens. We have enabled logs on iis to confirm app pool is not being recycled. IIS is also set to recycle once a day in the morning and no limits are set on iis to force recycle
This happens very randomly and not able to reproduce at all. We use Formsauthentication, but the site determines if it should be redirected back to the login page by looking if 2 critical session variables exists(sometimes the sessions are cleared even while authenticated aswell. We use default In-Proc session State.
We have tried response.redirect(...,false) when setting variables without any luck. This happens on a single server.
We are somehow running a web farm(Login screen handles the load and redirects to a server, but user stays on that server, until he logs out).
Any help in the correct direction will be appreciated!
I have implemented application in MVC3 with razor, it working absolutely fine in my development server, after deploying it on serve(Use IIS7 with windows2008) if site keeps idle for 10 to 15 minutes, after that clicking on any link it redirect to Home Page.
I have also set Session timeout on server.
please let me know how i can resolve this issue. Is this Session issue?
First, set the machineKey in your web.config -- see http://aspnetresources.com/tools/machineKey for a generator. This may solve your issue straight up.
If this doesn't resolve the issue, the cause could be several things. Your application could be being unloaded by IIS due to inactivity, or recycled due to excessive memory usage. Both these would terminate all sessions. Another possibility is your authenticated session has expired, if you are authorizing users.
This idle period can be extended through IIS, if necessary. In IIS configuration manager, locate the Application Pool your application is in, right click it and choose 'Advanced Settings' then alter 'Idle Time-out (minutes)'. Note that the default is 20 minutes, more than you are experiencing.
Verify it is not recycling due to excessive memory usage by watching the w3p process in Task Manager. If you see your instance growing large, then disappearing, this is likely the cause.
Last possibly is if you are using Forms authentication and the ticket has expired, your web.config file may be directing people to home page.
Just installed IIS Express 7.5 and am trying to debug a concurrency issue in an ASP.NET MVC 3 application. I don't however seem to be able to get the web server to process requests concurrently, they just get executed one by one.
I'm running Apache Bench to simulate a concurrent load but it's just getting queued up.
Anybody got any ideas?
Thanks.
If you are using sessions and reusing the Session ID for your concurrent requests, ASP.NET will queue the requests because it needs an exclusive lock on the session for each request.
Taken from http://msdn.microsoft.com/en-us/library/ms178581.aspx
Concurrent Requests and Session State
Access to ASP.NET session state is exclusive per session, which means
that if two different users make concurrent requests, access to each
separate session is granted concurrently. However, if two concurrent
requests are made for the same session (by using the same SessionID
value), the first request gets exclusive access to the session
information. The second request executes only after the first request
is finished. (The second session can also get access if the exclusive
lock on the information is freed because the first request exceeds the
lock time-out.) If the EnableSessionState value in the # Page
directive is set to ReadOnly, a request for the read-only session
information does not result in an exclusive lock on the session data.
However, read-only requests for session data might still have to wait
for a lock set by a read-write request for session data to clear.
You don't have anything odd in your web.config for the app do you such as settings for maxConcurrentRequestsPerCPU, maxConcurrentThreadsPerCPU?
http://msdn.microsoft.com/en-us/library/dd560842.aspx
This is a bit of a throwback question, and probably relatively fundamental, but I'm at a loss.
How does IIS manage Classic ASP session state?
We have an app that stores user information in session, and when many users are using the app, it seems to be recycling session for users, even though the "expire period" has not elapsed.
We suspect that when a certain amount of memory has been used for the session state, it begins to recycle the oldest session objects or something like this.
If this is correct, is there some way to control for it with the existing application code?
Thanks!
ASP sessions are stored as simple in memory COM objects when the process hosting the ASP application are terminated so will all the sessions.
ASP does not "recycle" active sessions. However there are number of other circumstances which can affect ASP sessions.
Application Pool Idle Timeout
One phantom reason "Sessions" appear to timeout prematurely is because the "Sessions" in question are just under test during development. Hence whilst the developer is examining the content of a page or reviewing some code no further requests hit the site since its not actually a live site.
In IIS manager open the properties of the pool in which your ASP application runs. Take a look at the Performance tab. The Idle Timeout will default to 20 minutes. Hence if you have specified a session timeout of say 60 minutes and you are "testing" that timeout you actually discover your session has timed-out in 20 minutes. The lack of activity has killed the application pool.
Application Pool Recycling
IIS may recycle the application pool in which the ASP application is running in. Recycling means that the existing set of processes currently hosting the ASP application no longer accept new requests. New requests go to a new set of processes and the older processes will terminate when they have completed their outstanding requests.
There are a whole host of different settings and criteria that can be configured that trigger the recycling of an application pool. Take a look at the Recycling tab of the pool properties dialog.
If you think that there may be an excessive demand for memory then the Memory recycling section may indicate a cause.
Web Garden
An Application Pool can contain multiple processes to run the same set of applications. Back on the performance tab note the Web Garden section at the bottom. By default this is set to 1. However multiple worker processes will play havoc with ASP sessions. As noted above ASP session are simple in-memory COM objects. If subsequent requests for a specific session are dished out to different workers one worker will not have access to the session object that the other has.
Session.Abandon or Session.Clear
Logic bugs can sometimes be the cause of sessions apparently disappearing. Calling the above methods at an inappropriate point in a sessions life can cause a problem.
I have experienced the same thing. Session seems to be emptied of the data, meaning that no variables is no longer stored in the session, but since the session exists, On_SessionStart doesn't trigger.
Gives you a headache if you initialize data for a visitor that you later on depends on...
I have considered this a bug that no one seems to know about, and haven't found a solution to it. It seems related to memory-usage, as you point out, and the solution seems to be to make sure you don't have any leaks.
Implement object-caching in classic ASP memory-leaking
This issue for me turned out to be the number of worker processes under the Performance tab. It was set to 2 for some reason. We set it back to 1 and the issue went away.