cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaakko Laine (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-572) handle old gossip properly
Date Thu, 10 Dec 2009 03:23:18 GMT


Jaakko Laine commented on CASSANDRA-572:

>From the small experiment (patch) it would seem that it is not too dangerous, just needs
a bit of extra care. From #617 it would seem that reducing total amount of data in the gossiper
would be beneficial, so current move gossip model needs some attention. There are basically
two options:

(1) use one state for all moves, and use tuple/triple in application state string to identify
what the node is doing (as suggested by jbellis earlier)
(2) return to the "old" gossip model: one state to broadcast the token and separate small
states to express what the token means. The reason for moving out of this model was to make
all needed information part of one gossip message and not rely on them arriving at the same
time. With small addition to StorageService, we might keep arriving token "somewhere" and
only add it to token metadata when the actual mode gossip arrives. This would take care of
the race condition and would also reduce the amount of data to be gossiped to bare minimum.

> handle old gossip properly
> --------------------------
>                 Key: CASSANDRA-572
>                 URL:
>             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.

View raw message