You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Caleb Rackliffe (Jira)" <ji...@apache.org> on 2020/11/18 21:20:00 UTC
[jira] [Updated] (CASSANDRA-16286) Make TokenMetadata's ring
version increments atomic
[ https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Caleb Rackliffe updated CASSANDRA-16286:
----------------------------------------
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable Corruption / Loss(12986)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.0-beta
3.11.x
3.0.x
Severity: Normal
Status: Open (was: Triage Needed)
> Make TokenMetadata's ring version increments atomic
> ---------------------------------------------------
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
> Reporter: Caleb Rackliffe
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear. The instance variable itself is {{volatile}}, but it is still incremented by a non-atomic check-and-set, and not all codepaths do that while holding the {{TokenMetadata}} write lock. We could make this more intelligible by forcing the external callers to use both the write when invalidating the ring and read lock when reading the current ring version. Most of the readers of the ring version (ex. compaction) don't need it to be fast, but it shouldn't be a problem even if they do. If we do this, we should be able to avoid a situation where concurrent invalidations don't produce two distinct version increments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org