Community
Participate
Working Groups
Build Identifier: 7.3.1 The jetty 7.3.1 HashSessionManager provides the ability to idle sessions out to disk. If however, a shared session store directory is used (for failover with a load-balancer), then a starting instance of jetty will attempt to restore and delete all idled sessions found in the store (at startup time or on the first scavenge if lazyLoad is set). If a request then comes in for the idled session, it can't be restored, because another (restarted) instance of jetty has already taken it. There's a very simple fix for this - in scavenge, don't do the following: try { if (!_sessionsLoaded && _lazyLoad) restoreSessions(); } catch(Exception e) { Log.debug(e); } Instead, allow lazyLoad to be even lazier and never restore a session until a request comes in for it. The only negative side effect as far as I can see is that if a request never comes in for a persisted/idled session, the session file will never be deleted. This can be solved in scavenge by scanning periodically for session files which have expired (by just checking the file date without loading the session). Background: It might sound like this is an obscure configuration but its very useful even in a single server configuration for zero-downtime rolling deploys - run the application twice on a single server on two ports with a HAProxy instance to distribute requests. Take the first instance down, update it, bring it up again, take the second instance down, update it, bring it up again - no downtime. Reproducible: Always Steps to Reproduce: 1. Run two instances of jetty with the HashSessionManager with session idling enabled and a shared session store directory 2. Restart one of the instances after some sessions from both instances have been idled. 3. The restarting instance will restore ALL sessions - not just his own. 4. A request coming in for an idled session to the instance which wasn't restarted will not find the idled session.
done r2951