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