Hi Guys, Thanks for your feedback. @André, I am working (not continually on the issue) on the issue, my mail (sent the day I started working on it) was just to have some additional analysis elements. I am happy to see bug has evolved and I followed the same exact path that one of the guys mentions, which is using a Load Test with a bit modified script to detect JSESSIONID mix. But unfortunately I didn't reproduce it. I will be working on it again this friday and will give as much feedback as I can.
Regarding upgrade to last Tomcat version , it is unfortunately not a short term option but it is not excluded, as you know in enterprise world moving UP a version for a big application is not an easy thing. Regarding the $consultant and the time , I can understand as I am also working on my spare time at Apache :-) @Christopher, we are already IN PROD on 1.2.40 of mod_jk and issue is happening. But we don't have yet the optimal (no retry) config in PROD, the first thing we will do is apply it on Load Test Env then prod to see if issue persists. Unfortunately reading further comments on bug, I see even after fixing this, issue persists (but will do it to be sure), and disabling connection reuse does not seem to be a good option on perf side, but it gives a hint that maybe the reused connection is not correctly cleaned up which could explain the "response mix". Regarding content length mentionned in bug , AFAIU this should be controlled by Tomcat (except for certain kind of responses like PDF generation where it is usually set by custom code). Thanks all for your answers. Regards On Thu, Sep 25, 2014 at 2:57 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Phillipe, > > On 9/7/14 5:49 PM, Philippe Mouawad wrote: > > I am working currently on an issue where an application is facing > > either Response mix or Session mix. For example: 1/ a user A gets > > the basket of customer B when going on basket detail (response > > mix) 2/ Cookies also get mixed up, more of session mix in this > > case > > > > The versions of components are the following: > > > > - Load Balancer => modjk_1.2.40 => Tomcat 5.5.23 (Yes very old) > > Yikes. > > > 1) Does the fix in mod_jk require an upgrade to a particular tomcat > > version ? > > No. mod_jk uses AJP13 protocol which all reasonably recent versions of > Tomcat (including 5.5!) support. Upgrading mod_jk should not be a > problem for you. > > > 2) The issue was related to a security problem, but how response > > mix did occur ? > > You'd have to read a whole lot more about the bug to understand that. > I'll paraphrase a recent statement: "this isn't a Hacking 101 course." > > > 3) The Bug 47714 close as Worksforme is not clear for me. Is it > > possible that non optimal config can lead to this issue, for > > example: > > > > - Not setting recovery_options ? what would be the technical > > explanation ? > > > > Request would be retried but how mix would occur ? > > I'm not sure. If we knew what the issue was, we probably would have > fixed it by now. Note that the resolution was WORKSFORME but it has > recently been re-opened along with some code that allegedly reproduces > the behavior. I haven't tried it myself, though. > > > I am besides this investigating load balancer and application > > issues. > > So you are experiencing response mix-ups as well? If so, please add > anything you can to that bug report. Of course, only after upgrading > to the most recent version of mod_jk. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJUJBE4AAoJEBzwKT+lPKRYLf8P/3lNsLdqxFWUt6htMqGaYFtl > rd3BcJw1ZepuzRFqfWaS8qvB5xV9/ZrbNQjSHk8r98ItvikM7wrbrCt24CX/WpvW > JrS+RnrirL2bmSM8Anvp3/akGnl+pbkUKz3DxqSHqT/T1MMLUU0hn3XwsZ/Sfhqq > Myg7jsODxVbYJWoXVx7IDYWTnd3JCXFCE+QUXX195QUY0iMNc5/eucpu/OtokZ6R > HnSjDZCtq2EKFFk/eXywUzBXpbNG9tmg4aTD0+VOsrnDVhFoWbAyQEe9NI2xTqpb > CiR9umcmAg3LxRUMLOXec3qdS6UQMzv7GXOCJ7JA5mI5EgV5GE/PFq+dbuGfNKNh > +gU17k9uypCtzgcG9e2J7guiYc24ZJ5W5ILtElfBwoyHXoW57iW57GOx0T0PdZge > 7NUCc3naBRjfjnWV77E1QKbeqKYnwQBAZdShTBChJVSQYsgOGPn6IqeILqn7za4d > P4bW+3v2qQPE9AeEYI+vKM3juy+hcsOK6vs8wKPDYhRxo+zc7ArwPfjZ1ry6MoPX > 1o3J0sYMEELrP786uoDILuKFNJ38outxBIiZ7Ce+KLyZBaUiGTqacD5zwevLwAS2 > w4GeJixYxKoQbUP90nBLdZMERM7ZJqFY7+1RWLiWkysMis8p0KiBt15reGATpD22 > Wvmxu6q9eMFaaU5DIKHF > =nPPd > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Cordialement. Philippe Mouawad.
