[
https://issues.apache.org/jira/browse/CASSANDRA-8516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14340731#comment-14340731
]
Tyler Hobbs commented on CASSANDRA-8516:
----------------------------------------
[~Stefania] I had a quick look at the code, and I think the root of the problem
is that {{updateNormalTokens()}} changes the node from the MOVING state to the
NORMAL state. Later, {{StorageService.handleStateNormal()}} is also called for
the node (this happens in response to gossip state changes); when it checks to
see if the node's state was MOVING, it has already been changed, so it believes
the node is joining.
That makes me think this isn't only a problem for single-node clusters.
Instead, the moving node will always emit a NEW_NODE notification, and every
other node will emit a MOVED_NODE notification.
As far as testing goes, I was just using a python script with debug logging
enabled, because the python driver will log any pushed notifications. However,
we do need a better testing method for this. I'll work on getting a dtest
environment set up for this real quick.
> NEW_NODE topology event emitted instead of MOVED_NODE in a one node cluster
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-8516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8516
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Tyler Hobbs
> Assignee: Stefania
> Priority: Minor
> Fix For: 2.0.13
>
>
> As discovered in CASSANDRA-8373, when you move a node in a single-node
> cluster, a {{NEW_NODE}} event is generated instead of a {{MOVED_NODE}} event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
