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

I think it is possible to handle the symptoms properly in serf via a combination of priority+windowing. The receiver should just allow storing the first window of data before it processes the rest.

Our current spillbuffer should handle this properly, as this is exactly what we do today with an update report that wants to fetch too many files.

Bert

Sent from Outlook Mail for Windows 10 phone

From: Ivan Zhakov
Sent: vrijdag 20 november 2015 10:27
To: Bert Huijben
Cc: dev_at_subversion.apache.org
Subject: 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