Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 11063 invoked from network); 9 Feb 2006 08:57:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Feb 2006 08:57:56 -0000 Received: (qmail 68777 invoked by uid 500); 9 Feb 2006 08:57:50 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 68727 invoked by uid 500); 9 Feb 2006 08:57:50 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 68712 invoked by uid 500); 9 Feb 2006 08:57:49 -0000 Delivered-To: apmail-jakarta-tomcat-dev@jakarta.apache.org Received: (qmail 68708 invoked by uid 99); 9 Feb 2006 08:57:49 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Feb 2006 00:57:49 -0800 Received: by ajax.apache.org (Postfix, from userid 99) id 54F2BCB; Thu, 9 Feb 2006 09:57:28 +0100 (CET) From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 37356] - Tomcat does not invalidate sessions after session-timeout period has passed. In-Reply-To: X-Bugzilla-Reason: AssignedTo Message-Id: <20060209085728.54F2BCB@ajax.apache.org> Date: Thu, 9 Feb 2006 09:57:28 +0100 (CET) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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=37356 ------- Additional Comments From tm@allocation.net 2006-02-09 09:57 ------- (In reply to comment #16) > I don't mean to throw a wrench in the works, but if that's true, wouldn't that > mean calling invalidate on the session later would NOT invalidate the session, > or does invalidate ignore the session access count? > > Also, I just wanted to confirm that there are no large files to download in our > system, so all of these users definately have an inactive connection--we're not > seeing normal system behavior waiting on files. > Most of all this happens in org.apache.catalina.session.StandardSession and org.apache.catalina.session.StandardManager. Calling invalidate() on the session more or less directly maps through to expire(), which will simply set the accessCount to 0 and remove the session from the sessionManager. After spending the whole of yesterday afternoon debugging I can also confirm, that it is indeed the accesssCount running out of sync. Alas, I still can not reproduce the problem. ( we found the wrong accessCount by running the failing production machine in debug mode and connecting to it with jdb) On my local (Windows XP) development machine with Sun-jdk 1.5.0_06, tomcat 5.0.28 and apache 2.0.55 connected through ajp13 (same setup as production, except for the OS) this simply does not occur. I also have second thoughts about the race condition theory, because one would expect, that such a thing would happen only once in a while - but on the servers we are seeing the issue on, it happens all the time (if not every time)... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org