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

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 20 Nov 2015 10:18:50 +0100

> -----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.

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.

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
Received on 2015-11-20 10:19:03 CET

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