[ 
https://issues.apache.org/jira/browse/CASSANDRA-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902511#action_12902511
 ] 

Gary Dusbabek commented on CASSANDRA-1216:
------------------------------------------

Some questions about the coordinator...  I see that removeToken() is 
quasi-blocking now, like unbootstrap() (it was fire-and-forget before).  What 
are the consequences of the coordinator node going down?  Assuming a dead 
coordinator, would it be Bad for another node to remove-token on the same token 
while the transfers initiated by the original failed coordinator were in 
process?  Or assuming the transfers were finished, would a remove-token on a 
new coordinator generally do little other than get the state to LEFT?

I think I'm of the opinion that removeToken should either block until the 
transfer is complete (or failed), or should return instantly, and that we need 
to make sure that subsequent removeToken calls do not upset existing transfers. 
 Having it return error after a timeout (which is possible in the case of LOTS 
of data) makes me think we should be doing differently.

Or is the only recourse to repair?

> 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 beta 2
>
>         Attachments: 0001-Add-callbacks-to-streaming.patch, 
> 0002-Modify-removeToken-to-be-similar-to-decommission.patch, 
> 0003-Fixes-to-old-tests.patch, 0004-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.

Reply via email to