On 20 November 2015 at 12:18, Bert Huijben <[email protected]> wrote: >> -----Original Message----- >> From: Ivan Zhakov [mailto:[email protected]] >> Sent: vrijdag 20 november 2015 10:12 >> To: Bert Huijben <[email protected]> >> Cc: [email protected]; [email protected] >> Subject: Re: svn commit: r1715228 - >> /subversion/trunk/subversion/libsvn_ra_serf/util.c >> >> On 20 November 2015 at 11:53, Bert Huijben <[email protected]> wrote: >> > Ack. >> > >> > Not pipelining, or not sending simultaneous/parallel requests if you don’t >> > want to depend on the order in which they are received is the safest thing. >> > >> > And the current code can break even in http/1. Svnrdump even has special >> > precautions for this even though I have no idea why it would see the >> > problems it describes it has. (The editor drive is 100% from one http >> > response) >> > >> > What we could do is replace the current assertion with a request on a >> > completely different connection to retrieve the properties if we don’t have >> > them in time… as a fallback mechanism to at least continue going. This also >> > works for legacy servers if the first improvement is applied. >> > >> > I’m not sure if the current implementation has more problems… E.g. if >> > revisions can also be received out of order. >> > >> > Going to a single report –that includes the revprops- for multiple >> > revisions >> > is a safe extension, that will improve in all cases: HTTP and HTTP/2 alike. >> > >> I understand that current is also unsafe, that's why I suggest go >> single REPORT and disable pipeling for older servers. I'll add this to >> my TODO list you agree that this approach makes sense. > > +1. > Ok, I'll try implement it. But I want release Subversion 1.9.3 first.
> This would solve +- 50% of the current testfailures running over http/2. > > But we should implement a fix that works for old servers too. I will work on > that part. > Yes, but I think disable pipelining is also viable option if we implement replay-range REPORT. > > At least some other failures I see are caused by getting httpd temporarily > in a 100% CPU loop, which causes other tests that run at the same time to > fail. My current best guess is that this is a server side issue, but I'll > have to > investigate. But not in the daytime hours of the next few days. > > > Note that the easiest way not to pipeline is: not scheduling requests that > you are not able to handle yet :) > > Bert > -- Ivan Zhakov
