Re: svn commit: r1715228 -/subversion/trunk/subversion/libsvn_ra_serf/util.c

On 20 November 2015 at 12:18, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>> Sent: vrijdag 20 november 2015 10:12
>> To: Bert Huijben <bert_at_qqmail.nl>
>> Cc: dev_at_subversion.apache.org; dev_at_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_at_qqmail.nl> 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