aratno commented on code in PR #4396:
URL: https://github.com/apache/cassandra/pull/4396#discussion_r2387762208
##########
src/java/org/apache/cassandra/replication/MutationTrackingService.java:
##########
@@ -92,8 +96,24 @@ public class MutationTrackingService
public static final MutationTrackingService instance = new
MutationTrackingService();
private final TrackedLocalReads localReads = new TrackedLocalReads();
- private final ConcurrentHashMap<String, KeyspaceShards> keyspaceShards =
new ConcurrentHashMap<>();
- private final ConcurrentHashMap<CoordinatorLogId, Shard> log2ShardMap =
new ConcurrentHashMap<>();
+ private ConcurrentHashMap<String, KeyspaceShards> keyspaceShards = new
ConcurrentHashMap<>();
+ private ConcurrentHashMap<CoordinatorLogId, Shard> log2ShardMap = new
ConcurrentHashMap<>();
+ private final ChangeListener tcmListener;
+
+ // prevents a race between topology changes (shard recreation) and
coordinator log creation.
+ //
+ // coordinator log creation can race with topology updates and be lost if
shard recreation discards the old
+ // KeyspaceShards containing newly created logs.
+ //
+ // the following usage patterns will guard against state corruption during
topology changes
+ // - Read lock: All normal operations (log creation, mutations, reads)
+ // - Write lock: Topology changes only (shard recreation during cluster
membership changes)
+ //
+ // Topology changes are rare vs shard recreation speed, so brief blocking
during cluster changes seems acceptable
+ // for correctness vs complex protocols topology updates. You could make
the case that mutable state would be
+ // a better tradeoff for node replacement, but it seems likely that
handling token movements will be simpler
+ // if we use a copy on write pattern for topology changes.
+ private final ReentrantReadWriteLock shardLock = new
ReentrantReadWriteLock();
Review Comment:
Yeah definitely, fine to defer
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
