-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael,
On 4/22/2009 12:25 AM, Menachem Husarsky wrote: > Christopher Schultz wrote: >> Are all your customers using Cookies? > > Yes. However, URL rewriting is disabled. Er.. how did you do this? Tomcat offers no way to disable URL rewriting. Or, did you implement one of those nasty jsessionid-stripping filters? > When I turn off cookies in > any of my browsers, our website's cart functionality will not work, > so if customers are complaining about their cart's being purged in > the middle of checkout it is not a cookie issue with their browsers. Okay. >> Do you ever switch hostnames during any of the website >> interactions? That would break your Cookie trail and you would >> observe the user's session "disappearing". The same thing can >> happen if the session cookie was created using HTTPS and then you >> switch to HTTP. > > > No we do not switch host names. customers start their sessions in > HTTP and switch to HTTPS to complete checkout. Not the other way > around. Good. The other way around is problematic. If you are instrumenting your application, you might consider logging the "secure" attribute of the session cookie being observed. If you find one marked as "secure" you could have a problem (and the solution is to only create session cookies in non-secure mode). >> Can you give us more information about the circumstances? Does it >> always happen during a particular page transition? What else do >> these failures have in common? > > It seems to happen during a transition from any one page to another, > but losing sessions, primarily interests me when it occurs during the > checkout process. we're recording the cart purge on various checkout > pages. Is the session actively killed, or does the client just lose track of the session id (or cookie, or whatever)? > I don't perceive any particular commonality. At first i thought it > was a browser issue, because it was happening to people who use IE 7. > However, recently I noticed it occurring to Mozilla Firefox users as > well. I have ruled out a browser issue client side as the culprit, > especially in light of the fact that this worked fine for years with > resin. One thing I have noticed is sometimes, a particular customer > would get their cart purged in the middle of a checkout session, and > then it would happen to the same customer/IP a few minutes later. > This is why i pursued the browser line of thinking, but it doesn't > explain why things worked fine for years in resin. Just remember that you didn't just change-out Resin for Tomcat. Your OP said that you changed hosting environments, too, so other factors are likely at play. If you now went back to Resin (replaced TC with Resin, but stayed with your current environment), I would expect that Resin would "fail" in the same way. > Right now I'm pursuing two lines of thinking: > > 1) somehow tomcat is in fact killing off the session, so on the next > request the user get's a new session, thus purging their cart since > our cart system uses sessions for storage. Tomcat will only kill the session if session.invalidate() is called, or if the session times out. I suspect you aren't explicitly setting your session timeouts, which means that they are getting the default timeout of 30 minutes. You can instrument your application by doing the following to see if the session is being killed by something during a request: 1. Write a Filter that... 2. wraps the HttpServletRequest with an object that... 3. intercepts calls to getSession and wraps the HttpSession object with... 4. an object that logs calls to the "invalidate" method Remember to log stack traces ;) > 2) somehow amid page redirects, tomcat doesn't get the session ID > from the browser and therefore issues to the browser a new session > ID, so although the cart exists under the old session object, the > user effectively loses their cart by receiving a new session. I would instrument the client using something like LiveHttpHeaders (when is Daniel going to support ff3.5?!) or IEHeaders (or whatever it is for MSIE) to see the chain of events that leads to session loss. Obviously, being able to reproduce this error is essential, so it's too bad that you haven't been able to do it yourself. If you have enough information in the web server logs, you can probably identify a problem case, then go back and look at their other requests to piece-together the chain of events. Note that Apache httpd can log cookie values if you ask it to do so, and I suspect that the AccessLogValve can do so, too. > Do you have any suggestions for me for how to debug this in a finer > more controlled fashion? Unfortunately, not being able to reproduce the problem is your biggest problem. Once you can do that, identifying and resolving the problem becomes *much* easier. Collecting more information when you identify these cases will certainly help with reproducibility. Good luck, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknvcOwACgkQ9CaO5/Lv0PDT4wCfRZRg0zZdYaQ2zM4bDr39nhPp Q4wAnAvDOGETcMgU95V+DSPCN+qvV6YH =QPFY -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
