Earlier I had a question about losing sessions regardless of timeout. (http://shiro-user.582556.n2.nabble.com/Losing-session-regardless-of-timeout-td7151602.html). This kind of ran out of steam, so I'll ask it a different way. Based on the responses to the earlier question and my own investigation, I'm inclined to suspect the cache - i.e., the problem is not that the session becomes explicitly invalidate, but rather that, due to some protocol hiccup, the distributed cache does not get a hit on the session id and so it looks invalid.
Now, it might not be RMI but RMICacheReplicatorFactory in EHCache. I think, from a cache's perspective, most use cases are very tolerant of occasional "false misses" because it can just go to the store behind the cache and get the uncached value. In our case, there is no session store behind the cache, so a miss logs the authenticated user out. A couple of things are working against this theory. RMI is quite mature and in my particular test case, it is not REALLY distributed - that is, I'm able to reproduce the error on a single machine, so it should be the easiest example to get right. Which leads to the question in my subject - is anyone really doing this really for real? Or is the RMICacheManagerPeerProvider really just for easy demos and you have to graduate to a "real" enterprise cache to do it reliably? -- View this message in context: http://shiro-user.582556.n2.nabble.com/Anyone-using-RMI-cache-replicator-in-production-tp7172831p7172831.html Sent from the Shiro User mailing list archive at Nabble.com.
