Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <003a01d12374$78c240b0$6a46c210$@qqmail.nl>
References: <20151119180312.8FB3E3A00E5@svn01-us-west.apache.org>
 <072601d1230d$be972ae0$3bc580a0$@qqmail.nl>
 <CABw-3YdW29U+ATUfdwxJfca32vhq2+oiwouPbDMgvqFAoCmf_g@mail.gmail.com>
 <073201d1231b$4fc08040$ef4180c0$@qqmail.nl>
 <073301d1231c$7560f540$6022dfc0$@qqmail.nl>
 <CABw-3Yfv0=KzC_RJnDGGfREx3ex0nb8aJaSavnLdALJ5PJ60oQ@mail.gmail.com>
 <564edfa0.2376c20a.ee8b6.ffffeb8f@mx.google.com>
 <CABw-3YeGW1OkM8etXGw6shy-dg6mNmkVEn9ge5DYLwm-vXc6uw@mail.gmail.com>
 <003a01d12374$78c240b0$6a46c210$@qqmail.nl>
From: Ivan Zhakov <ivan@visualsvn.com>
Date: Fri, 20 Nov 2015 12:27:08 +0300
Message-ID: 
 <CABw-3Yc6WY-UWqJE8LnbCJ3T-Q2A-JS1bxhfmiyB=foQrCQiaQ@mail.gmail.com>
Subject: Re: svn commit: r1715228
 -/subversion/trunk/subversion/libsvn_ra_serf/util.c
To: Bert Huijben <bert@qqmail.nl>
Cc: dev@subversion.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 20 November 2015 at 12:18, Bert Huijben <bert@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
>> Sent: vrijdag 20 november 2015 10:12
>> To: Bert Huijben <bert@qqmail.nl>
>> Cc: dev@subversion.apache.org; dev@serf.apache.org
>> Subject: Re: svn commit: r1715228 -
>> /subversion/trunk/subversion/libsvn_ra_serf/util.c
>>
>> On 20 November 2015 at 11:53, Bert Huijben <bert@qqmail.nl> wrote:
>> > Ack.
>> >
>> > Not pipelining, or not sending simultaneous/parallel requests if you d=
on=E2=80=99t
>> > want to depend on the order in which they are received is the safest t=
hing.
>> >
>> > And the current code can break even in http/1. Svnrdump even has speci=
al
>> > 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=
=E2=80=99t have
>> > them in time=E2=80=A6 as a fallback mechanism to at least continue goi=
ng. This also
>> > works for legacy servers if the first improvement is applied.
>> >
>> > I=E2=80=99m not sure if the current implementation has more problems=
=E2=80=A6 E.g. if
>> > revisions can also be received out of order.
>> >
>> > Going to a single report =E2=80=93that includes the revprops- for mult=
iple revisions
>> > is a safe extension, that will improve in all cases: HTTP and HTTP/2 a=
like.
>> >
>> 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 temporaril=
y
> 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 tha=
t you are not able to handle yet :)
>
>         Bert
>


--=20
Ivan Zhakov