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

Re: more handy post-M3 tips

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-04 00:34:38 CEST

On Mon, Sep 03, 2001 at 10:02:20PM +0100, Joe Orton wrote:
> the client does a REPORT with body
> <S:update-report xmlns:S="svn:">
> <S:entry rev="29"></S:entry>
> <S:missing>notes</S:missing>
> </S:update-report>
> but then half way through reading the response body, starts a GET using
> the same session! (an assert() in neon somewhere would have made that
> easier to diagnose, hmmmm)

Eek! That isn't good at all. Thanks for the pointer on that one...

Hmm. Basic design flaw in the update processing. We process the XML and
attempt to do the operations during the scan (rather than buffer all
instructions in memory, then execute). But (of course) we cannot do a GET or
PROPFIND or anything like that because we're still processing the REPORT

I bet the only way it happens to work is if the REPORT body fits into the 8k
buffer that you use to read inside Neon. (it isn't going to be a single
network packet, cuz I'm assuming the inbound TCP buffers are already holding
the fully response, but that could certainly vary... so say 1500 to 8000
bytes of response)

Note that just having Neon pun a GET request while processing the REPORT
won't be the answer. That would eliminate the future chance of HTTP
pipelining (that is: sending one request while working on it). You just
can't *process* them out of order :-)

Hoo boy... this is going to be an ugly one to fix. The cheap way is to open
a second session, but I don't like that one at all. Buffering in memory
could be impossible for a large update. Setting and abandonment threshold
isn't all that attractive either...



Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:39 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.