[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273928#comment-17273928
]
Andres de la Peña commented on CASSANDRA-16286:
-----------------------------------------------
The patches also look good to me. It seems that the bug also affects 2.1 and
2.2. I'm not sure if the bug is critical enough to go in 2.1, but probably we
should apply it to 2.2 even when we are very close to its end of support with
4.0 release. The patch seems to apply cleanly to older branches, we'd only have
to be careful to replace the lambda function in the test by a classic anonymous
class. wdyt?
> 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
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
