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=37356>. 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
