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
