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