You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefania (JIRA)" <ji...@apache.org> on 2015/03/04 05:41:05 UTC
[jira] [Comment Edited] (CASSANDRA-7816) Duplicate DOWN/UP Events
Pushed with Native Protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346387#comment-14346387 ]
Stefania edited comment on CASSANDRA-7816 at 3/4/15 4:40 AM:
-------------------------------------------------------------
Submitting a patch for 2.0, cassandra_7816.txt.
The duplicate DOWN notification is caused by {{Gossiper.handleMajorStateChange}} passing the remote endpoint state to {{StorageService.onRestart}}, which then incorrectly comes to the conclusion that the node was not previously marked down. I changed it to receive the local state, if not null. If it is null we do not call {{onRestart}}, please confirm that this does not introduce problems (I checked all {{onStart}} implementations and it looks OK to me).
The multiple UP notifications are caused by the call to {{markAlive()}} in {{Gossiper.applyStateLocally()}} when receiving multiple gossip messages. Because {{markAlive()}} only marks the node as alive after receiving an echo message (CASSANDRA-3533), there is a delay during which the node is still not marked as alive. If gossip messages are received during this period, we incorrectly call {{markAlive()}} multiple times in {{applyStateLocally()}}. I fixed it by adding a flag to {{EndpointState}} and by checking this flag in {{markAlive}}, if an echo is outstanding then we do not send another one until we've received an answer. When there is a major change, {{markAlive()}} is called on the remote state, for which this flag is not set and so we try againg sending an echo message in mark alive even if we did not receive a reply to a previous echo request.
was (Author: stefania):
Submitting a patch for 2.0.
The duplicate DOWN notification is caused by {{Gossiper.handleMajorStateChange}} passing the remote endpoint state to {{StorageService.onRestart}}, which then incorrectly comes to the conclusion that the node was not previously marked down. I changed it to receive the local state, if not null. If it is null we do not call {{onRestart}}, please confirm that this does not introduce problems (I checked all {{onStart}} implementations and it looks OK to me).
The multiple UP notifications are caused by the call to {{markAlive()}} in {{Gossiper.applyStateLocally()}} when receiving multiple gossip messages. Because {{markAlive()}} only marks the node as alive after receiving an echo message (CASSANDRA-3533), there is a delay during which the node is still not marked as alive. If gossip messages are received during this period, we incorrectly call {{markAlive()}} multiple times in {{applyStateLocally()}}. I fixed it by adding a flag to {{EndpointState}} and by checking this flag in {{markAlive}}, if an echo is outstanding then we do not send another one until we've received an answer. When there is a major change, {{markAlive()}} is called on the remote state, for which this flag is not set and so we try againg sending an echo message in mark alive even if we did not receive a reply to a previous echo request.
> Duplicate DOWN/UP Events Pushed with Native Protocol
> ----------------------------------------------------
>
> Key: CASSANDRA-7816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7816
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Michael Penick
> Assignee: Stefania
> Priority: Minor
> Fix For: 2.0.13, 2.1.4
>
> Attachments: cassandra_7816.txt, tcpdump_repeating_status_change.txt, trunk-7816.txt
>
>
> Added "MOVED_NODE" as a possible type of topology change and also specified that it is possible to receive the same event multiple times.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)