Hi Pieter, On Wed, Mar 25, 2020 at 01:42:14AM +0100, Olivier Houchard wrote: > Hi Pieter, > > On Wed, Mar 25, 2020 at 01:14:46AM +0100, PiBa-NL wrote: > > Hi List, Willy, > > > > Today i thought lets give v2.2-dev5 a try for my production environment ;). > > Soon it turned out to cause SVN-Checkout to stall/disconnect for a > > repository we run locally in a Collab-SVN server. > > > > I tracked it down to this commit: 493d9dc (MEDIUM: mux-h1: do not blindly > > wake up the tasklet at end of request anymore) causing the problem for the > > first time. Is there something tricky there that can be suspected to cause > > the issue.? Perhaps a patch i can try? > > > > While 'dissecting' the issue i deleted the whole directory each time and > > performed a new svn-checkout several times. It doesn't always stall at the > > exact same point but usually after checking out around +- 20 files something > > between 0.5 and 2 MB. , the commit before that one allows me to checkout > > 500+MB through haproxy without issue.. A wireshark seems to show that > > haproxy is sending several of RST,ACK packets for a 4 different connections > > to the svn-server at the same milisecond after it was quiet for 2 seconds.. > > The whole issue happens in a timeframe of start of checkout till when it > > stalls within 15 seconds. > > > > The 'nokqueue' i usually try on my FreeBSD machine doesn't change anything. > > > > Hope you have an idea where to look. Providing captures/logs is a bit > > difficult without some careful scrubbing.. > > > > Regards, > > PiBa-NL (Pieter) > > > > No answer yet, but I just tried to do a checkout of the FreeBSD svn tree > via haproxy, and it indeed doesn't work, it's a bit late right now, but > I'll have a look tomorrow :) >
I think I figured it out, and commit 69664419d209d2f64dbcd90f991e7ec2efff2ee2 should fix it, at least now I can do a full svn checkout. Can you confirm it does the trick for you ? Thanks ! Olivier
