[
https://issues.apache.org/jira/browse/CASSANDRA-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915227#action_12915227
]
Gary Dusbabek commented on CASSANDRA-1216:
------------------------------------------
This looks good.
1. There were a few unused local variables in SS.retoreReplicationCount().
Was this just leftovers from a rebase?
2. SS.handleStateRemoving removes a null check that previously existed for
epThatLeft (renamed removeEndpoint). Was the original null-check pointless or
was something missed in the change?
3. You made a change to StreamHeader that made me think you were running into
cases where SH.pendingFiles == null. Is that true? Tracing the codepaths
makes me think this is not possible.
Don't bother with the cleanup in 1. I'm more curious about 2 and 3.
> removetoken drops node from ring before re-replicating its data is finished
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-1216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1216
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7 beta 1
> Reporter: Jonathan Ellis
> Assignee: Nick Bailey
> Fix For: 0.7.0
>
> Attachments:
> 0001-Modify-removeToken-to-be-similar-to-decommission.patch,
> 0002-Additional-tests-for-removeToken.patch
>
>
> this means that if something goes wrong during the re-replication (e.g. a
> source node is restarted) there is (a) no indication that anything has gone
> wrong and (b) no way to restart the process (other than the Big Hammer of
> running repair)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
