> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> Sent: donderdag 19 november 2015 23:12
> To: Bert Huijben <bert_at_qqmail.nl>
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1715228 -
> /subversion/trunk/subversion/libsvn_ra_serf/util.c
>
> 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?
In theory we could... we could set the initial window to 0 and then send a window update later. Assuming that httpd does that efficiently, etc. etc. (Some of these assumptions are most likely not true)
But I doubt if it would be more efficient than just sending the request when we need it... or perhaps asking the properties a revision earlier. (We can also send the request, but just leave out the end of stream marker... Sending EOS will then handle the request)
The http/1 style just send all the requests early just doesn't work out in case we want to handle them in strict order. In this very specific case it might even be more efficient to just use http/1.1. The way we currently want to handle it, is really like one big bulk request.
I remember that we even disabled pipelining in some of these cases (perhaps we still do).... This really needs a better design on the Subversion side.
Bert
Received on 2015-11-19 23:40:53 CET