tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 37356] - Tomcat does not invalidate sessions after session-timeout period has passed.
Date Tue, 07 Feb 2006 17:49:02 GMT
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 Lothsahn@yahoo.com  2006-02-07 18:49 -------
(In reply to comment #10)
> (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

We're seeing this issue on our NON-SSL Apache ajp13 system...  so I don't think
SSL is a requirement for this issue to occur.

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


Mime
View raw message