cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-572) handle old gossip properly
Date Mon, 07 Dec 2009 20:39:18 GMT

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

Jonathan Ellis edited comment on CASSANDRA-572 at 12/7/09 8:37 PM:
-------------------------------------------------------------------

The fundamental question is, is it ever dangerous to overwrite intermediate states, such that
a node who has been down or partitioned does something broken when it gets the latest [partial]
information?

> if we do not do that, a modest 30s network outage might cause us not to see STATE_LEFT

Trying to figure out what you're referring to here...  We can't miss a STATE_LEFT from a node
that is leaving permanently since that will remain its last state and will be gossiped forever.
 And if we miss a STATE_LEFT from a node that is moving, a down node that comes back up later
will get the new token location and "snap" it to the right spot immediately.

I assume that as usual I am slow on the uptake here. :)

      was (Author: jbellis):
    The fundamental question is, is it ever dangerous to overwrite intermediate states, such
that a node who has been down or partitioned does something broken when it gets the latest
[partial] information?
  
> handle old gossip properly
> --------------------------
>
>                 Key: CASSANDRA-572
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-572
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.5
>            Reporter: Jaakko Laine
>             Fix For: 0.5
>
>         Attachments: 572-handle-old-gossip.patch, use-same-APstate-for-all-node-state-gossip.patch
>
>
> (1) If a node has been moving in the ring, further bootstraps by other nodes will cause
errors as they are handling STATE_LEAVING gossip without having such member in token metadata.
> (2) When a node bootstraps, it handles all ep states in the order they happen to arrive.
If the first one to arrive has moved in the past (that is, it has STATE_LEAVING in its ep
state), getNaturalEndpoint will throw ArrayIndexOutOfBounds exception as sortedTokens.size()
== 0.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message