Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 92768 invoked from network); 8 Feb 2006 17:12:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Feb 2006 17:12:13 -0000 Received: (qmail 30046 invoked by uid 500); 8 Feb 2006 17:12:07 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 29987 invoked by uid 500); 8 Feb 2006 17:12:06 -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 29972 invoked by uid 500); 8 Feb 2006 17:12:06 -0000 Delivered-To: apmail-jakarta-tomcat-dev@jakarta.apache.org Received: (qmail 29933 invoked by uid 99); 8 Feb 2006 17:12:05 -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; Wed, 08 Feb 2006 09:12:05 -0800 Received: by ajax.apache.org (Postfix, from userid 99) id 6ED0FCB; Wed, 8 Feb 2006 18:11:44 +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: <20060208171144.6ED0FCB@ajax.apache.org> Date: Wed, 8 Feb 2006 18:11:44 +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 Lothsahn@yahoo.com 2006-02-08 18:11 ------- (In reply to comment #15) > > We're seeing this same issue, as well. We're using tomcat 5.5.4, and we appear > > to only see it in environments under heavy load when using the ajp13 connector. > > We have another customer redirecting from IIS and they're not experiencing this > > issue. > > > > I spent a couple hours looking at the code and I didn't see anything weird. > > What I can tell you is that for the sessions this occurs on, their inactivity > > time IS properly set, but they still don't get invalidated. When I call > > invalidate on those sessions, they ARE invalidated. > > [...] > > Those sessions which fail to invalidate stay around forever--or seemingly so. > > I've seen inactivity times in the 2500+ minutes range. > > > This all fits into the threads issue theory. > Tomcat maintians a reference count for each session which is increased at the > beginning of a request and decreased at he end of the request. > > If - for whatever reason - this reference count does not reach zero after all > requests have finished (e.g. because one thread was increasing while another was > decreasing, or an exception occurred which is not propably handled or... ) > tomcat will not invalidate the session because it thinks there is still some > request currently running (which basically is a good thing. I do generally NOT > want my session to expire while a request is still running: e.g. a large download ) > > But this is still only a theory - I need to find a few free minutes to implement > a test case... 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. -- 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