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.
> I will start looking in supporting priority scheduling anyway…. But that
> requires more work in other parts of serf first. (I can’t use the request as
> an argument while serf still thinks it can destroy and recreate requests at
> a different address at will as part of the auth handling)
>
>
Ack.
--
Ivan Zhakov
Received on 2015-11-20 10:12:44 CET