I still haven't got to the bottom of this, but I've discovered a bit more about the problem. It's not actually triggered by the logout method (SecurityUtils.getSubject().logout()), but happens immediately afterwards. The key bit in the stacktrace seems to be this:
Caused by UnknownSessionException: There is no session with id [43608294-24be-478c-8082-de288379de13] ->> 170 | readSession in org.apache.shiro.session.mgt.eis.AbstractSessionDAO - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 261 | readSession in org.apache.shiro.session.mgt.eis.CachingSessionDAO | 236 | retrieveSessionFromDataSource in org.apache.shiro.session.mgt.DefaultSessionManager It's trying to read the session from the SessionDAO and as there is no such session, the exception occurs. But why should it be trying to read the session from the SessionDAO at this point? My understanding is that the cache mechanism in use should have deleted the session from the DAO as a result of the logout call. I'm using my own CacheManager implementation based on Redis, but the problem occurs even if I disable this and just use the inbuilt cacheing mechanism. -- View this message in context: http://shiro-user.582556.n2.nabble.com/What-might-cause-an-UnknownSessionException-tp7578179p7578183.html Sent from the Shiro User mailing list archive at Nabble.com.
