Johan Corveleyn <jcor...@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
