[
https://issues.apache.org/jira/browse/CASSANDRA-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986083#action_12986083
]
Brandon Williams commented on CASSANDRA-1900:
---------------------------------------------
Right. The problem here is that decommission and removetoken are completely
different operations (decom moves its own data off, removetoken has the
replicas restore the count.) So if a decommission fails, you need to invoke
the removetoken path, but since decommission puts the node's state in
STATE_LEAVING, you can't call removetoken currently. This patch removes that
restriction. If, for some reason, the streaming during removetoken fails, then
finally you need to removetoken force.
> Make removetoken force always work
> ----------------------------------
>
> Key: CASSANDRA-1900
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1900
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Affects Versions: 0.7.0 rc 2, 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Fix For: 0.7.1
>
> Attachments: 1900-v2.txt, 1900.txt
>
>
> The 'removetoken force' command was intended for forcing a removal to
> complete when the removal stalls for some reason. The most likely reason
> being a streaming failure causing the node to wait forever for streams to
> complete.
> The command should be updated so that it can force a removal in any case. For
> example a node that was decommissioned but killed before a LEFT status was
> broadcasted. This leaves the node in a permanent 'leaving' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
