[
https://issues.apache.org/jira/browse/CASSANDRA-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-1518:
----------------------------------------
Attachment: 1518.txt
Updated patch allows tokens to be taken over by new IPs. Note that I had to
change some logic in StorageService for this to work:
{code}
if (currentNode == null || (FBUtilities.getLocalAddress().equals(currentNode)
&& Gossiper.instance.compareEndpointStartup(endpoint, currentNode) > 0))
{code}
The problem here is if node X knows about token T belonging to node Y, and node
Z tries to take over this token, X will refuse to allow it because Z is not X.
Instead:
{code}
if (currentNode == null || Gossiper.instance.compareEndpointStartup(endpoint,
currentNode) > 0)
{code}
Will always rely on the heartbeat generation to determine if the token
ownership should be changed.
> remember ring state between restarts
> ------------------------------------
>
> Key: CASSANDRA-1518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1518
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Brandon Williams
> Fix For: 0.7.0
>
> Attachments: 1518.txt
>
>
> default behavior should be to remember the nodes we've seen before. we're
> already storing ip/token pairs in systemtable, but we're not removing them
> when removetoken is issued.
> we probably want to leave some trace of
> nodes-that-used-to-participate-but-were-removed, but instead of having a
> historical track in systemtable let's just add something to the gossip
> listener in StorageService that logs token when a node comes up.
> finally, there should be a flag (-D? config?) for bringing up a node in
> don't-assume-anything-about-the-ring mode as a fallback in case we run into
> more funky token-related bugs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
