You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lieven Govaerts <sv...@mobsol.be> on 2011/05/19 00:54:57 UTC

Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

On Wed, May 18, 2011 at 5:53 PM, <cm...@apache.org> wrote:

> Author: cmpilato
> Date: Wed May 18 15:53:04 2011
> New Revision: 1124306
>
> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
> Log:
> * notes/berlin-11-agenda
>  Add my first-pass notes about the discussions we've had here in
>  Berlin.  Others may wish to fill in more of the details as they
>  recall them.
>
> Modified:
>    subversion/trunk/notes/meetings/berlin-11-agenda
>
> Modified: subversion/trunk/notes/meetings/berlin-11-agenda
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
>
> ==============================================================================
> --- subversion/trunk/notes/meetings/berlin-11-agenda (original)
> +++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04
> 2011
> @@ -5,12 +5,17 @@ discuss, and make themselves merry.
>
>  [ should we include an expected attendee list? ]
>
> -Potential items for discussion:
> +POTENTIAL ITEMS FOR DISCUSSION
> +==============================
> +
>  * Let's finish Subversion 1.7
> + * Externals discussion
>  * ra_serf issues
>    - Should we leave serf as default http library?
>    - Checkout/update editor memory and performance issues. May be
>      it is worth implementing non-skelta update editor mode in ra_serf.
> +   - Serf request ordering problem when re-submitting for authn.
>

What is the "serf request ordering problem"? Never heard of any problems
with that code.
Lieven

Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/19/2011 12:54 AM, Lieven Govaerts wrote:
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven

I'd better let Ivan explain that, as it was from he that I learned of the
problem just this morning.  Ivan?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Greg Stein <gs...@gmail.com>.
Likewise. We asked Ivan to file a bug about it.
On May 19, 2011 12:55 AM, "Lieven Govaerts" <sv...@mobsol.be> wrote:
> On Wed, May 18, 2011 at 5:53 PM, <cm...@apache.org> wrote:
>
>> Author: cmpilato
>> Date: Wed May 18 15:53:04 2011
>> New Revision: 1124306
>>
>> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
>> Log:
>> * notes/berlin-11-agenda
>> Add my first-pass notes about the discussions we've had here in
>> Berlin. Others may wish to fill in more of the details as they
>> recall them.
>>
>> Modified:
>> subversion/trunk/notes/meetings/berlin-11-agenda
>>
>> Modified: subversion/trunk/notes/meetings/berlin-11-agenda
>> URL:
>>
http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
>>
>>
==============================================================================
>> --- subversion/trunk/notes/meetings/berlin-11-agenda (original)
>> +++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04
>> 2011
>> @@ -5,12 +5,17 @@ discuss, and make themselves merry.
>>
>> [ should we include an expected attendee list? ]
>>
>> -Potential items for discussion:
>> +POTENTIAL ITEMS FOR DISCUSSION
>> +==============================
>> +
>> * Let's finish Subversion 1.7
>> + * Externals discussion
>> * ra_serf issues
>> - Should we leave serf as default http library?
>> - Checkout/update editor memory and performance issues. May be
>> it is worth implementing non-skelta update editor mode in ra_serf.
>> + - Serf request ordering problem when re-submitting for authn.
>>
>
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven

Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Jun 3, 2011 at 00:17, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Jun 2, 2011 at 15:57, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>>> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@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

Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 2, 2011 at 15:57, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@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.

Cheers,
-g

Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@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)

-- 
Ivan Zhakov

Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@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

Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, May 25, 2011 at 05:03, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Wed, May 18, 2011 at 10:38 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> What is the "serf request ordering problem"? Never heard of any problems
>>> with that code.
>>> Lieven
>>>
>> I've filled issue 72 in serf issue tracker:
>> http://code.google.com/p/serf/issues/detail?id=72
>>
>> I'm not sure should I add an issue for that to Subversion issue tracker too.
>
> Thanks for the report - please see r1469.  It should fix this issue.  -- justin
>
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.



-- 
Ivan Zhakov

Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 18, 2011 at 10:38 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> What is the "serf request ordering problem"? Never heard of any problems
>> with that code.
>> Lieven
>>
> I've filled issue 72 in serf issue tracker:
> http://code.google.com/p/serf/issues/detail?id=72
>
> I'm not sure should I add an issue for that to Subversion issue tracker too.

Thanks for the report - please see r1469.  It should fix this issue.  -- justin

Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, May 19, 2011 at 00:54, Lieven Govaerts <sv...@mobsol.be> wrote:
> On Wed, May 18, 2011 at 5:53 PM, <cm...@apache.org> wrote:
>
>> Author: cmpilato
>> Date: Wed May 18 15:53:04 2011
>> New Revision: 1124306
>>
>> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
>> Log:
>> * notes/berlin-11-agenda
>>  Add my first-pass notes about the discussions we've had here in
>>  Berlin.  Others may wish to fill in more of the details as they
>>  recall them.
>>
>> Modified:
>>    subversion/trunk/notes/meetings/berlin-11-agenda
>>
>> Modified: subversion/trunk/notes/meetings/berlin-11-agenda
>> URL:
>> http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
>>
>> ==============================================================================
>> --- subversion/trunk/notes/meetings/berlin-11-agenda (original)
>> +++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04
>> 2011
>> @@ -5,12 +5,17 @@ discuss, and make themselves merry.
>>
>>  [ should we include an expected attendee list? ]
>>
>> -Potential items for discussion:
>> +POTENTIAL ITEMS FOR DISCUSSION
>> +==============================
>> +
>>  * Let's finish Subversion 1.7
>> + * Externals discussion
>>  * ra_serf issues
>>    - Should we leave serf as default http library?
>>    - Checkout/update editor memory and performance issues. May be
>>      it is worth implementing non-skelta update editor mode in ra_serf.
>> +   - Serf request ordering problem when re-submitting for authn.
>>
>
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven
>
I've filled issue 72 in serf issue tracker:
http://code.google.com/p/serf/issues/detail?id=72

I'm not sure should I add an issue for that to Subversion issue tracker too.

-- 
Ivan Zhakov