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

Re: Failing svnrdump_tests.py#43 with 1.7.x on Windows

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Fri, 10 Feb 2012 09:05:06 +0000

Johan Corveleyn <jcorvel_at_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

> - 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
Received on 2012-02-10 10:05:57 CET

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