[
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)