On 20 November 2015 at 00:03, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: rhuijben_at_apache.org [mailto:rhuijben_at_apache.org]
>> Sent: donderdag 19 november 2015 19:03
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1715228 -
>> /subversion/trunk/subversion/libsvn_ra_serf/util.c
>>
>> Author: rhuijben
>> Date: Thu Nov 19 18:03:11 2015
>> New Revision: 1715228
>>
>> URL: http://svn.apache.org/viewvc?rev=1715228&view=rev
>> Log:
>> Add a tiny bit of code to allow testing with Apache Serf's http/2 support.
>>
>> I committed this patch to celebrate that I got through basic_tests.py
>> using the current http/2 support.
>>
>> * subversion/libsvn_ra_serf/util.c
>> (conn_negotiate_protocol): New function.
>> (conn_setup): Register usage of conn_negotiate_protocol when
>> a very recent (read: trunk) serf + SVN__SERF_TEST_HTTP2 are used.
>
> Currently most tests pass for me over http2 when running with some minor tweaks. I still get some aborted connections that aren't retried as cleanly as with http 1.1. Not sure what causes these yet; but this could also be an httpd issues.
>
> The only ra function that really causes problems is the implementation of the replay
> range api. This 100% expects that results will be received in the same order in which
> they are sent. This is typically the correct way in http 1.1 using serf, but even there it
> is sometimes possible to get results out of order. (Authentication can re-queue
> requests... and sometimes authorization is necessary even when earlier requests
> succeeded, depending on the auth scheme).
>
Can we use WINDOW_UPDATE frame to control flow of replay-revision
response? In this case we can use spillbuf for buffering responses to
avoid latency performance regressions. What do you think?
--
Ivan Zhakov
Received on 2015-11-19 23:13:00 CET