cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9765) checkForEndpointCollision fails for legitimate collisions
Date Wed, 15 Jul 2015 21:41:04 GMT

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

Jason Brown commented on CASSANDRA-9765:
----------------------------------------

bq. this method should be called in {{checkForEndpointCollision}} as follows and replace all
other conditions

Yes, sorry about not specifying that.

bq. In your method the first is not allowed and the last two are both allowed, ...

Oops, I meant to disallow all three states; I did say it "might not be 100% correct yet" :).
You correctly fixed that in your version of the method. As for BOOTSTRAP ...

bq. According to CASSANDRA-7939 BOOTSTRAP should be allowed

Yes, you are correct about that point; STATUS_BOOTSTRAPPING should not be in that {{states}}
list. 

WRT the tests, you list indeed looks good. As to the "killing a node starts gossiping but
before we change it's gossip status", I really don't have a good suggestion that doesn't involve
injecting some failure state or a goofy timing trick. I think if we can get coverage over
the other states (as you've done) I think we can still consider this a big win.

nits: 
- As the {{ApplicationState}} is actually called STATUS, and not STATE, let's be consistent
about calling it "status" inside {{Gossiper}} at least for anything you might be changing.
- let's rename {{getApplicationState}} to {{getGossipStatus}} or simply {{getStatus}}. There's
another "node status" running around ({{StorageService.operationMode}}), which is another
'state' for the node (used internally), and I'd just like to keep that as distinct as we can
from the Gossip status (which is, largely, used externally)




> checkForEndpointCollision fails for legitimate collisions
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-9765
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9765
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Richard Low
>            Assignee: Stefania
>             Fix For: 2.0.17
>
>
> Since CASSANDRA-7939, checkForEndpointCollision no longer catches a legitimate collision.
Without CASSANDRA-7939, wiping a node and starting it again fails with 'A node with address
%s already exists', but with it the node happily enters joining state, potentially streaming
from the wrong place and violating consistency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message