Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
From: Philip Martin <philip.martin@wandisco.com>
To: Johan Corveleyn <jcorvel@gmail.com>
Cc: Greg Stein <gstein@gmail.com>,  Paul Burba <ptburba@gmail.com>,
  dev@subversion.apache.org
Subject: Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows
References: 
 <CAB84uBUryfDpoKdROEWQUbVeVWu=QRURjYsS=+-auSFEMt-fNw@mail.gmail.com>
	<20120209164915.GB4576@daniel3.local>
	<CAO16vNSECDuo0eU1Br1B3yFZGK9pzVzAQPkeSxtsub5Mn3p4Ow@mail.gmail.com>
	<CABD8fLWK+2vZWejeitBijJV0sNPATP9aJmjkxPyxPjm54gxwng@mail.gmail.com>
	<CAB84uBU-dJf+xmDP3Yjrf4w+32iH0-m47fyACxJUB1Sdjma2tA@mail.gmail.com>
	<CAO16vNSMuwSkazEnK7auE0fR_9995Z2==ujAQLD+3CF4pfaW7w@mail.gmail.com>
	<CABD8fLXpOY6t4H7UVye9HTX5YTo_dbumTsBBBR08nrmbV57=Tg@mail.gmail.com>
	<CAB84uBWFk9+2pnj2SDO-jWTj3XNxvnD0T3=psfq7Rr1t=iN=0g@mail.gmail.com>
Date: Fri, 10 Feb 2012 09:05:06 +0000
In-Reply-To: 
 <CAB84uBWFk9+2pnj2SDO-jWTj3XNxvnD0T3=psfq7Rr1t=iN=0g@mail.gmail.com>
	(Johan Corveleyn's message of "Fri, 10 Feb 2012 01:02:25 +0100")
Message-ID: <87ipjfhxdp.fsf@stat.home.lan>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Johan Corveleyn <jcorvel@gmail.com> writes:

> I'm finally starting to get somewhere:
>
> (all the below is with a trunk client with MAX_NR_OF_CONNS=1, vs. the
> affected mod_dav_svn)
>
> When processing 'psi', update_editor.c#handle_fetch exits early. It
> skips the last block of 'if (APR_STATUS_IS_EOF(status))' (containing
> the 'close_file' call), because status==730035. That seems to be
> WSAEWOULDBLOCK (WinError.h): "A non-blocking socket operation could
> not be completed immediately."
>
> After that, for some reason, the close_directory is driven first, and
> only later handle_fetch is run again to finish off psi.

Ah!  So it's using fetch_ctx->read_headers to allow multiple calls to
handle_fetch.  I understand that now.

> That might explain the Windows-ness a bit (specific socket behavior),
> combined with some randomness (sometimes it does "complete
> immediately", sometimes it doesn't). It still doesn't explain the
> relatedness to 1.7.x.
>
> Open questions:
>
> - What's the link with Philip's change in liveprops.c ('if (kind !=
> svn_node_file) return DAV_PROP_INSERT_NOTSUPP;') ?

None really.  That change causes the server to avoid sending a
checksum="###error###" line for direcories, but all that matters in this
context is that changing a server response affects the timing of all the
server responses.

svnrdump/serf falls over at random depending on the order in which it
receives responses from the the (multi-threaded/multi-process) server.
It can fall over using a 1.7.2 client against a 1.6 server.  By changing
the timing we cause svnrdump/serf to fall over at random in a different
place.

> - Why the WSAEWOULDBLOCK error? Maybe that's expected and normal, and
> shouldn't cause a problem in and of itself?

Yes. The response to a GET request could be large.  So the client may
have to loop to read it all.  That loop happens outside handle_fetch.

> - Why, after exiting handle_fetch early, does ra_serf first do the
> close_directory first? I don't know much about how ra_serf organizes
> these things.

That's where the server timing comes in.  After the first call to
handle_fetch for psi if the next event is the rest of the GET then we go
back into handle_fetch and things are OK.  But sometimes some other
event happens first and we do close_directory.

> (actually, the WSAEWOULDBLOCK error also happens earlier during the
> update-drive, when adding trunk/D/G/rho, but it doesn't cause a
> problem -- no close_directory interference, just a clean "rerun" of
> handle_fetch).

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com