[Deploying Sakai] Anyone had users losing Sakai sessions unexpectedly?
lydial at stanford.edu
Thu Jan 12 13:45:22 PST 2012
I would like to find out if anyone in the Sakai community has had reports from users saying they were unexpectedly logged out from Sakai. Recently, one instructor reported that a couple of his students were logged out during a final and all students were on wired connection in the same room. We are not sure how often this happens, since we suspect if this happened outside of a final, users would just log back in and not bothered with filing a ticket. We have not been able to reproduce the problem ourselves.
Has anyone else in the community heard similar reports from users?
Our system administrator, Julian Morley (cc'd here), has provided a description of our production environment, along with his analysis of the situation. We would appreciate if anyone has any insights.
"Our app servers are fronted by an F5 BigIP load balancer. It has 2
virtual servers ; one that handles http, the other https. Both virtual
servers support 'sticky sessions', but how they handle it differs. The
address. The https virtual server uses SSL sessionID (obviously not an
option for http) and then source IP address.
Our login flow looks like this:
A user goes to http://coursework.stanford.edu, hitting the HTTP
virtual server which balances them to one of the app servers and sets
a cookie so all their interactions remain 'stuck' to that app server
until their session ends or is timed out (after 60 mins of
inactivity). This lasts for precisely 1 second until the app server
says 'oi, all traffic goes thru httpS!' and redirects them to
This, in turn, sends the user back to the loadbalancer - this time
they get an SSL session ID from the loadbalancer and get re-balanced,
via the HTTPS virtual server, to an app server. The app server may
(but probably won't be) the same as handled their http session. But
this session will be 'stickified' to that app server by the SSL
session ID, with an idle timeout of 60 minutes. The user can then log
on (getting bounced through webauth), etc. We know this works through
empirical testing : if the webauth redirect sent them to a different
app server, they'd not be able to log on since that app server has no
clue about the initial webauth request.
What I think is happening is either:
1. Some subtle weirdness with the loadbalancer swallowing sessions in
the persistance table, or
2. Some subtle weirdness with Sakai swallowing java sessions, or
3. Mod_jk dropping the ball between Apache and Tomcat.
Any of which would kill the end-user's Sakai experience."
More information about the production