[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

From: Lieven Govaerts <lgo_at_apache.org>
Date: Tue, 9 Jul 2013 13:19:07 +0200

Hi Philip,

On Tue, Jul 9, 2013 at 12:01 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Lieven Govaerts <lgo_at_apache.org> writes:
>> Note, again: Serf will not have a feature to automatically detect that
>> servers don't support chunked requests. Such a check is implemented in
>> ra_serf with the extra OPTIONS request, there's no other way to do
>> this without the extra roundtrip.
> There is another way: rely on the fact that all client operations from
> the client start with non-pipelined requests. During this phase ra_serf
> recognises the 411 for the first chunked request, switches to C-L mode
> and retries the request. There is still an extra request, but only when
> the proxy is present. My patch to implement this allows 90% of the
> regression tests to PASS, if I could get the ra_serf code to retry the
> update REPORT request I think just about all the tests would PASS.

I wouldn't make that assumption.

First of all, because that's not guaranteed to be or stay that way.
Take for instance svnsync. It currently sends two non-pipelined
OPTIONS requests (to my surprise) from:
1. svn_ra_serf__exchange_capabilities
2. svn_ra_serf__v2_get_youngest_revnum

I consider the request sent by svn_ra_serf__v2_get_youngest_revnum in
this case a bug. The second OPTIONS request and response is identical
to the first, the only reason why it's sent is because ra_serf doesn't
cache the latest revision number from the response to the first

So suppose I fix that bug, your assumption isn't valid anymore for svnsync.

Second, IMO the bottleneck is not in having to send the extra second
request, but the fact that we have to wait for the response to any
second request before we can start pipelining the 3rd,4d... request.
It's better to send two small requests to find out the capabilities of
the whole chain asap, instead of having to retry a potentially
expensive update REPORT (takes time to create, to spool to disk, to
re-read and stream over the network).

> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
> www.wandisco.com

Received on 2013-07-09 13:20:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.