Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Wait for read repair before responding #5
Our philosophy up to this point has been to respond to the client as soon as possible and execute a repair asynchronously if one was warranted. This caused occasional problems where a client would receive a 409 Conflict response to an update request based on the Reply that we had just sent if the repair was too slow to execute.
This patch changes the behavior so that in most cases we delay responding to the client until the repair has completed. The only case where we still respond quickly and issue an asynchronous repair is if we achieved the read quorum and the only alternative replies that we received were ancestors of the quorum reply.
To clarify, I'd say we can remove the configurability altogether and just make it blocking. If users ask for asynchronous repairs we can reconsider, but we've seen the case where a subsequent write request wins the race with the repair job and fails with a conflict. It isn't pretty.
Actually, I take it back. I think there is one case where we should respond before the repair, and that's if
a) we achieved the quorum, and
For instance, in a situation where one of the copies is missing just the latest revision.