DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=15463>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=15463 StandardManager incorrectly uses getLastAccessedTime [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2004-05-03 21:29 ------- Problems with expiring sessions have been reported numerous times. The basic problem is as follows, starting at time 0 min and with a max inactive interval of 30 minutes: 00 min: First request, new session created, LastAccessedTime 0 02 min: Second request, reuse session, LastAccessedTime 0 31 min: Third request, reuse session, LastAccessedTime now 2 33 min: Background manager thread expires session even though it has only been two minutes since the remote clients last request. The argument for not changing how this works is based on how the Servlet Spec defines Session.getLastAccessedTime(). But I agree with all those who have complained about this behaviour that Tomcat session timeouts are buggy. So I came up with a compromise that still allows the HttpSession.getLastAccessedTime() to return the time of the previous request for those who are Servlet Spec purists. But internally sessions are expired when current time > last request + max inactive interval. When we do a major revision we should consider adding the StandardSession.getLastUsedTime() method to the org.apache.catalina.Session interface. Patch committed to CVS. Will be available in 4.1.31 and later releases. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
