On Sat, Apr 11, 2015 at 2:16 AM, Willy Tarreau <[email protected]> wrote: > Hi David, > > On Thu, Apr 09, 2015 at 04:01:44PM -0700, David Birdsong wrote: > > Ok, false alarm. > > > > We have corruption in our log parsing stream so that's what the rest of > my > > week will be centered around. > > OK, "cool" (for the rest of us). I was suspecting that the captures were > initialized too late and were showing data from previous sessions (which > could have been possible). > > However there's something that worries me in what you're writing : > > > >> > For the time > > >> > being, we're stuck at 1.5.5 since 1.5.6 changes hashes for > path-based > > >> > hashing. We're working on re-arranging our infra to not take such a > hit > > > >> were > > >> > our working set request hashing to be redrawn which will happen > with >= > > >> > 1.5.6. > > What's the problem exactly ? Is it related to this patch ? >
Yes, this will redraw our entire cache. > > commit ac0329261bc9f4001e9d313ee879d193c05ca56e > Author: Willy Tarreau <[email protected]> > Date: Fri Oct 17 12:11:50 2014 +0200 > > BUG/MEDIUM: backend: fix URI hash when a query string is present > > Commit 98634f0 ("MEDIUM: backend: Enhance hash-type directive with an > algorithm options") cleaned up the hashing code by using a centralized > function. A bug appeared in get_server_uh() which is the URI hashing > function. Prior to the patch, the function would stop hashing on the > question mark, or on the trailing slash of a maximum directory count. > Consecutive to the patch, this last character is included into the > hash computation. This means that : > > GET /0 > GET /0? > > Are not hashed similarly. The following configuration reproduces it : > > mode http > balance uri > server s1 0.0.0.0:1234 redir /s1 > server s2 0.0.0.0:1234 redir /s2 > > Many thanks to Vedran Furac for reporting this issue. The fix must > be backported to 1.5. > (cherry picked from commit fad4ffc89337277f3d5ed32b66986730e891558a) > > If so, is there anything that could be done in haproxy to work around your > issue. I mean, we're talking a great care of not introducing regressions > in the stable branch, which is why I don't want to see any feature > backports > there anymore (I learned my lesson with 1.4). So if we can do anything so > that 1.5.12 is a safe upgrade for you, please suggest. > I don't think we need a work-around. We're only stuck because our system expects a level of cache locality that the hash provides. A sudden redraw would be pretty disastrous, but we're working on removing this cache locality requirement and we'll be able to upgrade to the latest version. Regards, > Willy > >
