[
https://issues.apache.org/jira/browse/CASSANDRA-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788469#action_12788469
]
Jaakko Laine edited comment on CASSANDRA-572 at 12/10/09 3:23 AM:
------------------------------------------------------------------
>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.
> I assume that as usual I am slow on the uptake here. :)
I think the problem is in my ability to clearly express an idea :)
was (Author: jaakko):
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: 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.
