[
https://issues.apache.org/jira/browse/CASSANDRA-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630269#comment-13630269
]
Jason Brown commented on CASSANDRA-5459:
----------------------------------------
seedProvider is private in DD with no public accessor. Since the current
DD.getSeeds() is simple enough (albeit with some extra collections wrapping
around it), it's not unreasonable to just reuse that, especially since
SeedProvider does not currently have any other method besides getSeeds()
Admittedly, I imitated how we do things in Gossiper.start(), but I see in my
patch I'm not excluding the node itself from the seeds list like start() does.
I will rework my patch slightly to have start() and removeEndpoint() use the
same seeds list building code.
> Remove node from seeds list when it permanently leaves the cluster
> ------------------------------------------------------------------
>
> Key: CASSANDRA-5459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5459
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1.10, 1.2.4, 2.0
> Reporter: Jason Brown
> Assignee: Jason Brown
> Priority: Minor
> Labels: gossip, seeds
> Fix For: 1.1.11, 1.2.5, 2.0
>
> Attachments: 5459-v1.patch
>
>
> When a node leaves the cluster for good (via removetoken, decommission, or is
> replaced via replace_token), we clean up all references to it in MS and
> Gossiper. However, we never remove the entry from the seeds list in Gossiper
> (if the node was a seed). This will cause Gossiper to still try to
> communicate with the removed node as we try to talk to a random seed on each
> round of gossip.
> The attached patch will remove the node from seed list when it leaves the
> cluster, and further, will call the SeedProvider for an updated list of
> seeds. In a dynamic environment like EC2, when a node dies or is replaced,
> that node is never coming back. Thus is it advantageous to get a refreshed
> set of seeds to help with the network partition healing aspect of gossip (we
> dynamically retrieve that list in Priam). This makes seeds a bit more of a
> dynamic concept, but it's rather essential in a dynamic cloud environment.
> I believe this also resolves that repeated log message like :
> {code}Nodes /10.217.XXX.YYY and /10.217.AAA.BBB have the same token
> 56713727820156410577229101240436610841. Ignoring /10.217.XXX.YYY{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
