cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-5459) Remove node from seeds list when it permanently leaves the cluster
Date Fri, 12 Apr 2013 16:38:17 GMT


Jason Brown updated CASSANDRA-5459:

    Attachment: 5459-v2.patch

This version slightly refactors Gossiper by pulling the seeds list building code out of start()
and into a shared method that removeEndpoint() will call.
> Remove node from seeds list when it permanently leaves the cluster
> ------------------------------------------------------------------
>                 Key: CASSANDRA-5459
>                 URL:
>             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, 5459-v2.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:

View raw message