Todd Lipcon has posted comments on this change. Change subject: WIP disk failure: forced shutdown of replicas ......................................................................
Patch Set 4: (1 comment) http://gerrit.cloudera.org:8080/#/c/7439/4//COMMIT_MSG Commit Message: PS4, Line 15: cannot end a transaction that is in the APPLYING state (must be : RESERVED), Cancels can end any transaction. This is only "safe" because : t currently I think we directly enter the 'APPLYING' state when we submit a transaction to the 'apply_pool', right? But in fact it could be either be (a) in the queue waiting to start actually applying, or (b) actually in the process of applying. In the first case (waiting in the queue) this seems reasonable and safe to do. In fact we should probably be doing this in _all_ tablet "shutdown" scenarios (eg DeleteTablet is a common case). If a transaction is still waiting to start applying, then simply aborting it and having it be a no-op when it exits the queue into the 'Apply' code path is safe (I don't think we have any clean way to remove it from the queue while waiting). In the second case (actually inside WriteTransaction::Apply) I don't think we can safely go in and do anything to the transaction object, and we truly do need to wait for it to finish, right? We could of course set some flag on the tablet itself indicating that it is being shut down, and peroidically check that flag while processing writes, and then Abort the transaction if we see it get set mid-write, but that's best-effort and essentially an optimization, right? As for "Abort" vs "Cancel", I'm trying to figure out what the distinction is here. I'm not necessarily against adding a new API, but we should be clear what the distinction is and whether it actually needs to behave any differently. From the transaction's view point, either is the same, right? In both cases you just want it to stop in its tracks as soon as possible and not write any COMMIT message to the log. -- To view, visit http://gerrit.cloudera.org:8080/7439 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I983620f27e7226806a2cca253db7619731914d42 Gerrit-PatchSet: 4 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Andrew Wong <[email protected]> Gerrit-Reviewer: David Ribeiro Alves <[email protected]> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Mike Percy <[email protected]> Gerrit-Reviewer: Todd Lipcon <[email protected]> Gerrit-HasComments: Yes
