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