Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <384344843.239891263482934473.JavaMail.jira@brutus.apache.org>
Date: Thu, 14 Jan 2010 15:28:54 +0000 (UTC)
From: "Jaakko Laine (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Updated: (CASSANDRA-644) Provide way to remove nodes from
 gossip entirely
In-Reply-To: <138350459.1261153159125.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jaakko Laine updated CASSANDRA-644:
-----------------------------------

    Attachment: 644-remove-from-gossip-on-removetoken.patch

yeah, that should probably be fixed. Attached patch should do the trick. I'll fix the other part tomorrow.

> Provide way to remove nodes from gossip entirely
> ------------------------------------------------
>
>                 Key: CASSANDRA-644
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-644
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 0.5
>            Reporter: Jonathan Ellis
>            Assignee: Jaakko Laine
>            Priority: Minor
>             Fix For: 0.9
>
>         Attachments: 644-remove-from-gossip-on-removetoken.patch
>
>
> As reported in CASSANDRA-634, "Now that we're gossiping about dead nodes as well, gossip digest continues to grow without boundary when nodes come and go. This information will never disappear as it will be propagated to new nodes no matter how old and obsolete it is. To counter this, we need some mechanism to (1) either remove dead node from endpointstateinfo or (2) at some point stop to gossip about it, or both."
> This is also seen when using "fat clients" that participate in the gossip ring; if a client leaves and does not come back it stays in the gossip forever.  (This can be confusing if the client does start up again, connecting to a _different_ cluster, but the old one notices it is back and starts gossiping to it again!)
> I would prefer to leave management of these things explicit; 3 days is long enough that the fat client problem in particular needs another solution, and if it needs another solution then that can become the only solution. :)
> So I would be in favor of removeToken clearing out gossip entries, and also adding a command to remove an endpoint from the gossip ring that does not have a token associated with it (like fat clients).  A command to ask "what are all the known gossip hosts" would also be useful, since nodeprobe ring only includes nodes w/ tokens.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.