Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
kvs: support ability to "revert" / "back out" merged commits #1346
As described in #1337, a failure in a merged commit should not fail all transactions that make up that commit. In order to accomplish this, this is what I did:
Ran soak tests over 1000 jobs, and overall performance is < 1% slower. Understandable that there is slowdown as there are additional allocations and what not.
(I should say, the "before" is before PR #1343, the refactor done right before this PR.)
Note, I used the word "revert" in the documentation and code to describe a failed merged commit becoming "un-merged". I'm not 100% happy with the use of this term to describe what's going on, but
Also, no unit tests at the moment for the kvs module, only some unit tests for the internal commit API. Outside of pure instrumentation, impossible to test as the commit merging is racy. It would be easier once #1341 is implemented, as a stress test across namespaces could be done.
@@ Coverage Diff @@ ## master #1346 +/- ## ========================================== + Coverage 78.47% 78.51% +0.03% ========================================== Files 162 162 Lines 29689 29739 +50 ========================================== + Hits 23298 23349 +51 + Misses 6391 6390 -1
garlick left a comment
Why does continuing to merge after a commit has begun processing prevent fallback on error?
Would be good to explain this in the commit message so that we aren't tempted to add it back later for performance if it would break something.
Ahh, I should change that commit log message. It's no longer true (was from a prior attempt). I left this in for another reason. Now that we are no longer removing commits from the queue, I'd have to regularly scan the ready queue to see if there are new things to merge.
That or keep a pointer to the "last merge" point. Hmmm. I suppose this would be doable, it's just a single pointer. Let me think about this.
Just re-pushed with updated patches based on current master. Discounting the renaming of data structures/variables/names/etc., changes are largely the same. I did decide to squash some patches into other ones.
The one notable difference is I removed my prior change where merges can only occur for transactions in state KVSTXN_STATE_INIT. I instead do not allow merges if a merge as already occurred. The net affect is identical, more clear, and does protect against a corner case where the user calls the merge function multiple times.
I put in the commit message why I did this and note that the reason for doing this could be optimized in the future. I may try and optimize before this PR is merged. Gonna think about it a bit, but didn't want that to be the hold up for pushing/merging this PR.
and two soak runs to compare
little surprised the mean is faster. Perhaps just a lucky run. Or atleast ballpark similar performance.