A few people have reported svn+ra_serf aborting when starting a merge operation.
Bert Huijben:
http://svn.haxx.se/dev/archive-2008-06/0066.shtml
Daniel Shahaf:
http://svn.haxx.se/dev/archive-2008-05/0017.shtml
I can reproduce this issue, but only from time to time. Typically I can
reproduce it once, and then I have to restart my machine to reproduce it again.
The issue happens when certain requests to the server fail and have to be
resent. Wwhat's happening is that ra_serf creates a bucket with the request
body, but that body is eaten and destroyed by the first request. So when the
request is sent a second time, typically the memory is not cleared yet so the
request will succeed, but on destroying that body for the 2nd time, serf will abort.
This is explained in more detail:
http://svn.haxx.se/dev/archive-2007-08/0153.shtml
The correct way of working is simple: instead of giving serf a bucket with the
request body, provide it with a callback that can create the bucket on demand,
twice if needed. We already do this for most of the request types, but not for
all. I could find 8 places where the body_buckets variable is still set. All
these places need to be converted to use body_delegate.
For REPORTs this is a bit difficult, as these are created when driving an
editor, which we don't want to drive a second time.
One of the workarounds is to store the data from the REPORT request on disk too,
and reload it if needed. Another workaround would be to teach the bucket code to
not destroy the bucket data until we explicitly told serf to do so.
Let's use this bug for the cleanup of those 8 'body_buckets locations'.
Bug
Major