This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit bec6bfde1f3b6a782f123f9f9ff18072a97e379f Author: N V Harikrishna <n.v.harikrishna.apa...@gmail.com> AuthorDate: Mon Feb 12 08:46:55 2024 +0000 Minor corrections to TCM Implementation document Patch by Venkata Harikrishna Nukala; reviewed by Sam Tunnicliffe for CASSANDRA-19247 --- src/java/org/apache/cassandra/tcm/TCM_implementation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/java/org/apache/cassandra/tcm/TCM_implementation.md b/src/java/org/apache/cassandra/tcm/TCM_implementation.md index 8fc0da5bbd..e161742504 100644 --- a/src/java/org/apache/cassandra/tcm/TCM_implementation.md +++ b/src/java/org/apache/cassandra/tcm/TCM_implementation.md @@ -54,11 +54,11 @@ At that point, the node is ready to start the process of joining the ring. It be * Ranges that will be affected by the bootstrap of the node are locked (see `LockedRanges`) * If computed locked ranges intersect with ranges that were locked before this transformation got executed, `PrepareJoin` is rejected. -* `InProgressSequence`, holding the three transformations (`PrepareJoin`, `MinJoin` `FinishJoin`), is computed and added to `InProgressSequences` map. +* `InProgressSequence`, holding the three transformations (`StartJoin`, `MidJoin` and `FinishJoin`), is computed and added to `InProgressSequences` map. * If any in-progress sequences associated with the current node are present, `PrepareJoin` is rejected. * `AffectedRanges`, ranges whose placements are going to be changed while executing this sequence, are computed and returned as a part of commit success message. -`InProgressSequence` is then executed step-by step. All local operations that the node has to perform between executing these steps are implemented as a part of the in-progress sequence (see `BootstrapAndJoin#executeNext`). We make *no assumptions* about liveness of the node between execution of in-progress sequence steps. For example, the node may crash after executing `PrepareJoin` but before it updates tokens in the local keyspace. So the only assumption we make is that `SystemKeyspac [...] +`InProgressSequence` is then executed step-by-step. All local operations that the node has to perform between executing these steps are implemented as a part of the in-progress sequence (see `BootstrapAndJoin#executeNext`). We make *no assumptions* about liveness of the node between execution of in-progress sequence steps. For example, the node may crash after executing `PrepareJoin` but before it updates tokens in the local keyspace. So the only assumption we make is that `SystemKeyspac [...] In order to ensure quorum consistency, before executing each next step, the node has to await on the `ProgressBarrier`. CEP-21 contains a detailed explanation about why progress barriers are necessary. For the purpose of this document, it suffices to say that majority of owners of the `AffectedRanges` have to learn about the epoch enacting the previous step before each next step can be executed. This is done in order to preserve replication factor for eventually consistent queries. --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org