Ben Reser <ben_at_reser.org> writes:
> On Sun, Dec 2, 2012 at 9:18 AM, Justin Erenkrantz <justin_at_erenkrantz.com> wrote:
>> As for the looping, didn't we put in logic to stop retrying after a number
>> of request failures? That's probably a reasonable thing to do...I
>> definitely think a very nice feature of serf is that it *will* retry (which
>> is helpful in flaky network situations), but it needs to stop at a certain
>> point. =) -- justin
>
> HTTP RFC suggests only 1 automatic retry on idempotent request sequences:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4
Retrying does make things really complicated with the current FSFS
implementation. In this case the server is aborting which means that
the recent FSFS change to introduce rep_write_cleanup will be defeated:
any partial representation data written to the protorev file will remain
in the file. It's not significant in this case because the transaction
will never become a revision, all the retries will fail in the same way.
However if the PUT failed because some other request in another thread
had crashed the process then the retry could succeed. Then we would end
up with a revision file that contained some unreferenced junk data.
If the PUT failed due to a network issue the retry may succeed if it is
proccessed by some other server process. If the retry is processed by
the same server process as the failed request then whether the retry
succeeds depends on whether the server has recognised the network
problem and run rep_write_cleanup.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-12-03 12:21:06 CET