[
https://issues.apache.org/jira/browse/CASSANDRA-10736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121865#comment-15121865
]
Joel Knighton commented on CASSANDRA-10736:
-------------------------------------------
I have patches for this and just need to verify if the changes in behavior to
{{getPredecessor}} and {{getSuccessor}} are necessary.
[~blambov] It looks like these changes went in as part of [CASSANDRA-7032].
Prior to this, in {{TokenMetadata}}, {{getPredecessor}} and {{getSuccessor}}
threw errors if tokens weren't in the endpoint map. After [CASSANDRA-7032], the
first token is selected. Is this an intended change? Tests continue to pass
with this reverted.
> TestTopology.simple_decommission_test failing due to assertion triggered by
> SizeEstimatesRecorder
> -------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-10736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10736
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
> Reporter: Joel Knighton
> Assignee: Joel Knighton
> Priority: Minor
>
> Example
> [here|http://cassci.datastax.com/job/cassandra-2.2_dtest/369/testReport/junit/topology_test/TestTopology/simple_decommission_test/].
> {{SizeEstimatesRecorder}} can race with decommission when it tries to get the
> primary ranges for a node.
> This is because {{getPredecessor}} in {{TokenMetadata}} hits an assertion if
> the token is no longer in {{TokenMetadata}}.
> This no longer occurs in 3.0 because this assertion has been removed and
> replace with different data.
> In both cases, the relationship between the set of tokens in
> {{getPrimaryRangesFor}} (passed in as an argument) and the set of tokens used
> in calls by {{getPredecessor}} (the system ones) should be investigated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
