On Fri, Jun 3, 2011 at 00:17, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Jun 2, 2011 at 15:57, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
>>> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>>> It's really hard reproduce problem, because it's related to timing of
>>>> sending and receiving requests. From the code my feeling that issue is
>>>> still exists, just in more complicated scenario with more requests but
>>>> I didn't find reproduction script.
>>>
>>> Can you give me an idea why you think the issue still exists? We'd be
>>> adding the new priority requests after all of the previously-queued
>>> (but unwritten) priority requests...so, unless I did a silly think-o,
>>> I don't see why it would if the situation matches what was described
>>> in the issue. -- justin
>>>
>> May be it's different issue, but in case if server doesn't require
>> authentication for all requests and allow anonymous access for some
>> requests:
>> C: GET /restricted/
>> C: GET /public/
>> S: 401 /restricted/
>> S: 200 /public/ (client gets notification that second request is completed)
>> C: GET /restricted
>> S: 200 /restricted (clients gets notification that first request is completed)
>
> I don't see how re-ordering GET requests is a problem. This will
> naturally occur since ra_serf uses multiple connections. The server is
> free to respond to each connection however it wishes. ... and if it
> does so... I'm not sure what actual problem that causes.
>
I agree that it is not a big problem to implement serf client (ra_serf
in our case) to be aware that requests can complete in different
order. But it's a problem of serf since our API promise that requests
will complete in the same order as they created.
You are right that in general ra_serf does not rely on requests
completion order, but:
1. During update we always send PROPFIND and GET requests for one file
on same connection and expect them completed in this order.
2. svnsync replay editor is definitely rely on that requests are
completed in the same order that there are created.
--
Ivan Zhakov
Received on 2011-06-02 22:28:58 CEST