Hey..... This turned out to be a bug in our code - nothing to do with Shiro. We're using Redis as a shared session store, but we were caching sessions locally in memory, to stop thrashing redis session reads.
So whenever we were reading the session, we'd get it from the hashmap. Once multiple nodes are being used behind a load balancer, this shows up as failures that happen on login sometimes (Session created on both nodes, but only one node has the session that's "authenticated") So it seems that we either need to: - use sticky sessions to ensure our local in memory cache is up to date. - remove our local in memory cache and always get the result from our session dao (redis) - change our cache to be a "per request" cache that just stores the session for the current requests. Session writes would always be written to our local cache and our session DAO. Session reads would first come from the session DAO, then they'd come from the per request cache. -- View this message in context: http://shiro-user.582556.n2.nabble.com/Any-special-consideration-needed-for-use-in-Load-Balancer-tp7579867p7579869.html Sent from the Shiro User mailing list archive at Nabble.com.
