Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
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: <bug-37356-78@http.issues.apache.org/bugzilla/>
Message-Id: <20060207150355.4598ECB@ajax.apache.org>
Date: Tue,  7 Feb 2006 16:03:55 +0100 (CET)

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 tm@allocation.net  2006-02-07 16:03 -------
(In reply to comment #8)
> Do you mean that wo browsers use the same session to access a page, or just the
> ( quite usual ) case that two people use the web application?
> 
> A: not the same session. Different IE browser will generate differnt session 
> ID.
> 
> That means in the included application B and C you get the session from
> application A?
> 
> Application != context for you?
> 
> A: yes.

Ok, so you can replicate the error if:
1. you have two or more simultaneous users accessing a page in your web application.
2. you have more than one application (servlet / jsp) within the same context,
so the session stays the same through all requests.
3. one of your servlets includes the output from other servlets/jsps

Did I get that right?
 
> 
> 
> So it seems that the common ground for all of us here is, that we have some
> objects in the session that implement the HttpSessionBindingListener or
> HttpSessionActivationListener.
> 
> A: I did not put any object implement the HttpSessionBindingLisener or 
> HttpSessionActivationListener in the session.
> 
Ah - I had thought so, because you mentioned you remove the objects from the
session when it expires. The only way known to me to do this is to implement one
of those Interfaces (can't remember which one currently)

> 
> I think with different thread ( when include the page in other application), 
> when it will operate the session object, it will not synchronize the session 
> object (or its filed accessCount).
>
That seems reasonable. If the access count is not properly synchronized it will
indeed become screwed eventually.
Yet it is strange that it will only occur in our application if we use the ajp13
connector with SSL requests. 
SSL on tomcat standalone - everyting OK.
Plain http through Apache httpd (Linux) with ajp13 - everything OK
SSL through Apache httpd (Linux) with ajp13 - No Session timeouts
SSL through IIS with ajp13 - No Session timeouts
Basically the same application on all machines...

I'll try and stress-test my testserver a little and see if I can reproduce it
with enough simultaneous requests

-- 
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