I've added this inside the system.web node of my web.config
<sessionState mode="InProc" timeout="600" />
but my sessions are timing out within 30 minutes.
is there something else I need to do to increase my session timeout length?
There is a forms authentication node in my web.config as well but I'm not using any authentication on the web site. The forms authentication has a timeout value of 2880...but again, I'm not doing any authentication at all...
but my sessions are timing out within 30 minutes.
I suspect it's IIS which is recycling the application pool after a certain time of inactivity. And since your sessions are stored in-memory their contents is wiped out of existence when the web server tears down the application domain.
Look at the properties of the application pool of your application in IIS. You will see that there are settings allowing to configure this. There are also conditions such as memory or CPU threshold limits when IIS might recycle your application pool. If you want durable sessions you need to make them out-of-proc (session state server or SQL).
Related
Assumptions -
There are 4 servers sitting behind a reverse proxy which acts as a load balancer
Load Balancer is purely load balancing and sends a request to any of the 4 servers depending on their current load
Users need to be authenticated for accessing this application, and some space should hold state of all users, as reverse-proxy is only load balancing
Application needs to scale beyond 4 servers, say to 4000 servers.
Question -
In a large scale multi-server system who holds state of all the users - load balancer, each server, separate server?
Is the state of all users saved on all servers so that the load balancer can send a request to any server? How does this scale to 100m users?
You can use sticky sessions. It enables the load balancer to bind a user's session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance. Read Sticky and NON-Sticky sessions.
Also let's say the instance gets killed due to some reason, in order to maintain the state, the authentication token and other information can also be saved on a separate redis cache, which is much faster to query. Read Session Management in microservices
In a stateless multi-server system, a separate server (authentication server) or a separate server cluster (authentication api) holds state of all users. If its a single authentication server for a large application, you can expect it to have RAM in the range of 100's of GBs, maybe more.
Nope, state of all users is usually not replicated on all application servers, it will be a huge waste of resources. Authentication server (or server cluster) may act as load balancer itself or forward all requests to a separate load balancer - true for a stateless application.
In a stateful application, individual servers hold state of users through sticky sessions.
If possible, try to keep your application stateless. A stateless application will have better performance and will be easier to scale out than a stateful application!
I need to set absolute session timeout (timeout the session regardless the user is active or not) in websphere liberty profile server for an application?
How do I do that ? I know inactivity timeout setting. But it is not the requirement, absolute timeout is the requirement.
Either you JAAS enable your application, activate the Lightweight Third Party Authentication (LTPA) and set the absolute time, regardless activity.
The default expiration time is 2 hours and is an absolute time, not based on user activities. After the 2 hours, the token expires and the user must log in again to access the resource. Liberty: Authentication
or
Just set the global session timeout in liberty to x seconds (which is for inactivity), and in your web application for each communication front it with a filter or something similar that checks the session getCreationTime and invalidate it if it exceeds x seconds. Also some good guide and reading here
In this case you will have session invalidity for both inactive and active users.
I have set the session timeout in my WebSphere as 3 Mins (Consider.Actual timeout I have set is 30 mins).I have kept my application open and just moving my mouse over the J2EE application and making some keypress which will not submit any pages.Even after 3 mins, the session of the application is retained.I need to confirm how the session is retained when some mouse move / keypress happens ? No request is being sent to server or no page submissions has been done.
The session timeout for my application is maintained only in server.
Thanks.
This sounds like it's due to WebSphere's use of the LTPA token for authentication. In summary:
When the web session expires a users credentials are not expired (you
are not forced to re-login). This is due to the WebSphere
implementation of LTPA tokens and more info on this is covered in the
IBM documentation.
When the LTPA token expires the users credentials
are expired (you are forced to re-login).
The web session timeout is
relative to user activity. That is, it resets to 0 when user activity
is detected.
LTPA token timeout is not related to user activity. It
will timeout after the amount of time from creation date no matter
what user activity is going on.
From http://www-01.ibm.com/support/docview.wss?uid=swg21078845:
Question 3
I want to force my users to re-login after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeout.
Answer 3
See the answer to this question in item 9 of the following developerworks article:
http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html
From that link you learn:
9- I want to force my users to login again after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeouts?
The WebSphere Application Server LTPA token expires based on the lifetime of the login session, not based upon inactivity. Thus, the WebSphere Application Server login session will not expire if the user performs no action for some period of time. However, the HTTPSession does expire based upon inactivity. If in your application you need to expire the use of an application based on idleness, you must explicitly code this in your application. You can capture when a user arrives with an expired session (really, a new session) and force them to login again if you think this is necessary. Keep in mind that doing this undermines Single Sign On across applications.
A second approach that is a slight variation on the first is to use HTTPSession.getLastAccessTime() to compute when the last client request occurred. If the time is too far into the past, you can of course fail the access and force a new authentication.
Either of these approaches can be made transparent to the application code through the use of servlet filters.
It should be noted that IBM Tivoli® Access Manager provides for lifetime- and idle-based authentication session timeouts.
Users often ask why WebSphere Application Server works this way. Why can't it timeout idle login sessions? The reason is because WebSphere Application Server is fundamentally a loosely coupled distributed system. Application servers that participate in an SSO domain don't need to talk to each other. They don't even have to be in the same cell. So, if you want to limit the idleness lifetime of an LTPA token (aka SSO token), you'd have to update the token itself with a last usage time on every request (or perhaps on the first request seen during a one minute interval). This means that the token itself would change frequently (meaning the browser would be accepting new cookies frequently) and that WebSphere Application Server would have to decrypt and verify the inbound token when it is seen to validate it. That could be expensive (WebSphere Application Server today only validates a token on the first use at each application server). It's not impossible to solve these problems with clever caching and such, but that's not how WebSphere Application Server works today.
I want to know the difference between sticky- and non-sticky sessions. What I understood after reading from internet:
Sticky : only single session object will be there.
Non-sticky session : session object for each server node
When your website is served by only one web server, for each client-server pair, a session object is created and remains in the memory of the web server. All the requests from the client go to this web server and update this session object. If some data needs to be stored in the session object over the period of interaction, it is stored in this session object and stays there as long as the session exists.
However, if your website is served by multiple web servers which sit behind a load balancer, the load balancer decides which actual (physical) web-server should each request go to. For example, if there are 3 web servers A, B and C behind the load balancer, it is possible that www.mywebsite.com is served from server A, www.mywebsite.com is served from server B and www.mywebsite.com/ are served from server C.
Now, if the requests are being served from (physically) 3 different servers, each server has created a session object for you and because these session objects sit on three independent boxes, there's no direct way of one knowing what is there in the session object of the other. In order to synchronize between these server sessions, you may have to write/read the session data into a layer which is common to all - like a DB. Now writing and reading data to/from a db for this use-case may not be a good idea. Now, here comes the role of sticky-session.
If the load balancer is instructed to use sticky sessions, all of your interactions will happen with the same physical server, even though other servers are present. Thus, your session object will be the same throughout your entire interaction with this website.
To summarize, In case of Sticky Sessions, all your requests will be directed to the same physical web server while in case of a non-sticky load balancer may choose any webserver to serve your requests.
As an example, you may read about Amazon's Elastic Load Balancer and sticky sessions here : http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html
I've made an answer with some more details here :
https://stackoverflow.com/a/11045462/592477
Or you can read it there ==>
When you use loadbalancing it means you have several instances of tomcat and you need to divide loads.
If you're using session replication without sticky session : Imagine you have only one user using your web app, and you have 3
tomcat instances. This user sends several requests to your app, then
the loadbalancer will send some of these requests to the first tomcat
instance, and send some other of these requests to the secondth
instance, and other to the third.
If you're using sticky session without replication : Imagine you have only one user using your web app, and you have 3 tomcat
instances. This user sends several requests to your app, then the
loadbalancer will send the first user request to one of the three
tomcat instances, and all the other requests that are sent by this
user during his session will be sent to the same tomcat instance.
During these requests, if you shutdown or restart this tomcat
instance (tomcat instance which is used) the loadbalancer sends the
remaining requests to one other tomcat instance that is still
running, BUT as you don't use session replication, the instance
tomcat which receives the remaining requests doesn't have a copy of
the user session then for this tomcat the user begin a session : the
user loose his session and is disconnected from the web app although
the web app is still running.
If you're using sticky session WITH session replication : Imagine you have only one user using your web app, and you have 3 tomcat
instances. This user sends several requests to your app, then the
loadbalancer will send the first user request to one of the three
tomcat instances, and all the other requests that are sent by this
user during his session will be sent to the same tomcat instance.
During these requests, if you shutdown or restart this tomcat
instance (tomcat instance which is used) the loadbalancer sends the
remaining requests to one other tomcat instance that is still
running, as you use session replication, the instance tomcat which
receives the remaining requests has a copy of the user session then
the user keeps on his session : the user continue to browse your web
app without being disconnected, the shutdown of the tomcat instance
doesn't impact the user navigation.
Let's say the user sends a request to get its profile, there won't be anything in the memory of our web application instance. we get the user profile from DB nit before sending the response, we save the data in the memory of let's say Instance3. But the next request from the same user can go to any instance.
When the request first comes to Instance3, that time it will create a session that will have a session id. when the response is sent to the client, the client is supplied with a cookie. so next time this client makes a request, this cookie will be attached to the request, the load balancer will look at the cookie, and the load balancer will know that that request has to be forwarded to Instance3. This is sticky session solution. Its downside is what if Instance3 goes down? the load balancer will route the request to other instances but they do not have a cache. All the users stored in Instance3 will have high latency. This will impact the reliability of your system.
If you store sessions in all instances, now you would have memory issues. Let's say if an instance could store 100 user sessions and you have 3 instances, you would be able to store 300 sessions. But if each instance stores each session, you will be able to store only 100 sessions in all of your 3 instances. So this will impact the scalability of your application.
sticky and non-sticky sessions are components of stateful replication. If you want higher scalability you do not cache anything on your web application instance, your web instance will hit the DB with every request but this will cause high latency.
A better way is stateless replication where you do not store anything on your application instance but instead, you use server-side caching (memcached/redis)
I am evaluating the case of using sticky sessions with Session replication in tomcat. From my initial evaluation, I thought that if we enable Session replication, then session started in one tomcat node will be copied to all other tomcat nodes and thus we do not need sticky session to continue sessions and the request can be picked up by any node.
But it seems that session replication is in general used with sticky sessions, otherwise the session id needs to be changed whenever the request goes to some other node. ref: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node
Can anyone explain what is the real use of session replication if you have to enable sticky session? Because then you would be unnecessarily copying the session on each node, when the request with a given session id is always going to the same node. It could be beneficial in case of a node crashing, but then that does not happen frequently and using session replication only for that seems like an overkill.
As Mindas explained it before :
When you use loadbalancing it means you have several instances of tomcat and you need to divide loads.
If you're using session replication without sticky session : Imagine you have only one user using your web app, and you have 3
tomcat instances. This user sends several requests to your app, then
the loadbalancer will send some of these requests to the first tomcat
instance, and send some other of these requests to the secondth
instance, and other to the third.
If you're using sticky session without replication : Imagine you have only one user using your web app, and you have 3 tomcat
instances. This user sends several requests to your app, then the
loadbalancer will send the first user request to one of the three
tomcat instances, and all the other requests that are sent by this
user during his session will be sent to the same tomcat instance.
During these requests, if you shutdown or restart this tomcat
instance (tomcat instance which is used) the loadbalancer sends the
remaining requests to one other tomcat instance that is still
running, BUT as you don't use session replication, the instance
tomcat which receives the remaining requests doesn't have a copy of
the user session then for this tomcat the user begin a session : the
user loose his session and is disconnected from the web app although
the web app is still running.
If you're using sticky session WITH session replication : Imagine you have only one user using your web app, and you have 3 tomcat
instances. This user sends several requests to your app, then the
loadbalancer will send the first user request to one of the three
tomcat instances, and all the other requests that are sent by this
user during his session will be sent to the same tomcat instance.
During these requests, if you shutdown or restart this tomcat
instance (tomcat instance which is used) the loadbalancer sends the
remaining requests to one other tomcat instance that is still
running, as you use session replication, the instance tomcat which
receives the remaining requests has a copy of the user session then
the user keeps on his session : the user continue to browse your web
app without being disconnected, the shutdown of the tomcat instance
doesn't impact the user navigation.
I think the only real benefit is to be able to shut down Tomcat instances without much thinking. Especially this applies today in cloud world (think Amazon AWS spot instances) when nodes can go on and off really often. Alternative to this would be to buy a decent load balancer which supports node draining. But decent load balancers are expensive, and draining takes time.
Another scenario I can think of is a (poor implementation of) shopping cart where items are kept in the HttpSession and shutting down would require the user to re-purchase them (which would likely lead to a lost sale).
But in most cases you're right - benefit of having both sticky sessions and session replication is very negligible.
Just to clarify configuration issues on JBoss 5.X in "all" base configuration with mod_jk. Setting sticky sessions in workers.properties file
worker.list=loadbalancer
... nodes configuration omitted
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=True
does not prevent session replication. In order to switch off session replication on JBoss we need to set in $JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode parameter to LOCAL.
Usually in sticky session scenario we don't want session replication, since we do not want additional overhead connected with significant amount of I/O operations needed to replicate sessions.
In fact, if go with sticky sessions, we do not need to run JBoss in "all" configuration, we might use "default" or "standard" based configuration.
The only thing that has to be done is change in $JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">