Comment 1 Greg Wilkins 2011-02-21 22:50:43 EST

r2813 

If lazyLoad is set, then getSession will attempt to restore any session ID that it does not find in memory.

Comment 2 Roger Armstrong 2011-02-22 04:05:22 EST

And if you don't like the potential single point of failure which a shared file system represents like a single point of failure, you can substitute it by file replication, which then gives you a true SPOF-free fault tolerance (although you have to ensure that persisted session files are replicated fast enough so that the file is replicated before the load-balancer fails the next request over).

Note that in both cases, when lazyLoad is on, you have the potential to have dead session files left around. Since they will no longer be loaded and deleted on startup, they will need to be cleaned up periodically (maybe scavenge can also detect dead session files and delete them).

Comment 3 Roger Armstrong 2011-03-01 16:30:12 EST

7.3.1-SNAPSHOT correctly avoids restoreSessions() on startup if lazyLoad is set. However, it calls restoreSessions() anyway on the first scavenge() after a start (because _sessionsLoaded=false), so all idled sessions get reloaded (and the files deleted).

This breaks the ability of the jetty instance which first gets the request from the load-balancer to pick up the session, since if either of the instances gets restarted it will eat all the sessions, even though it has not received a request from the load-balancer for that session. Meanwhile, the load-balancer may redirect the request to the other instance which will then not be able to restore the session since it has already been taken by the other instance.

To fix this, you could either not call restoreSessions during scavenge if lazyLoad is set (this would have the side-effect that orphaned session files would not get deleted) or load them only temporarily to check if they are stale, and if not, leave the file alone. Given that the purpose of idling sessions out is to avoid burdening the system with them, it probably doesn't make sense to load all idled sessions on every scavenge, even if only temporarily. Maybe on every 100th scavenge, check if they're stale and delete them (or even just check the lastModified timestamp on the file and if its stale, delete it).

Comment 4 Roger Armstrong 2011-03-02 03:13:36 EST

Just to provide additional context for comment 3. The reason why this is important is because during a rolling deploy the jetty instances are stopped and restarted in sequence. If the scavenge() issue described occurs, then sessions will be moved arbitrarily to other instances during the rolling deploy (which is a disaster for any users of the application since they will lose their sessions).

Comment 5 Greg Wilkins 2011-12-22 01:47:23 EST

I think this was fixed with 5dcd74cda5acbf703a459aaad1d945a7a4b70616.

Please reopen if more is needed