[
https://issues.apache.org/jira/browse/CASSANDRA-16796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16796:
----------------------------------------
Fix Version/s: (was: 4.0.x)
(was: 3.11.x)
(was: 3.0.x)
4.0.1
3.11.11
3.0.25
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/fbb20b9162b73c4de8a82cf4ffdde3304e904603
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks, cleaned up those unused imports and committed to 3.0 and merged to 3.11
-> 4.0 -> trunk.
> Clear pending ranges for a SHUTDOWN peer
> ----------------------------------------
>
> Key: CASSANDRA-16796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16796
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0.1
>
>
> If a node involved in a MOVE operation should fail, peers can sometimes
> maintain pending ranges for it even when it has left the ring and/or been
> replaced (in practice until the peer is next bounced). This in turn can lead
> to bogus unavailable responses to clients if a replica for the any of the
> pending ranges should go down.
> If the moving node crashes hard, a subsequent replacement will correctly fail
> as long as cassandra.consistent.rangemovement is set to true because the new
> node will learn the MOVING status from the remaining peers. A graceful
> shutdown, however, causes that status to be replaced with SHUTDOWN, but
> doesn't update TokenMetadata, so pending ranges remain for the down node,
> even after it has been removed from the ring.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
