Ben Reser <b...@reser.org> writes: > On Sun, Dec 2, 2012 at 9:18 AM, Justin Erenkrantz <jus...@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
