cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3895) Gossiper.doStatusCheck() uses isMember() suspiciously
Date Mon, 13 Feb 2012 02:28:59 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206627#comment-13206627
] 

Peter Schuller commented on CASSANDRA-3895:
-------------------------------------------

{quote}
If fat clients disappear, no one really cares because they were never ring members.
{quote}

Ok. Well, they care in the joining (bootstrapping) node case since they are taking writes.
But all nodes will naturally drop them by themselves without needing others to propagate.
As long as we consider aVeryLongTime (3 days) long enough that it's safe to assume that this
only triggers in legitimate cases, we're fine (if not, we're not as soon as CASSANDRA-3892
is fixed or if I am wrong and it's not a bug to begin with).

I'll resolve this as WONTFIX then, though I'm skeptical about the 3 day very long time.

                
> Gossiper.doStatusCheck() uses isMember() suspiciously
> -----------------------------------------------------
>
>                 Key: CASSANDRA-3895
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3895
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Peter Schuller
>            Assignee: Peter Schuller
>            Priority: Minor
>
> There is code for fat client removal and "old" endpoint (non-fat) removal which uses
{{TokenMetadata.isMember()}} which only considers nodes that are joined (takes reads) in the
cluster.
> aVeryLongTime is set to 3 days.
> I could very well be wrong, but the fat client identification code, the way I interpret
it, is using isMember() to check basically whether a node is "part of the cluster" (in the
most vague/broad sense) in order to differentiate a "real" node (part of the cluster) from
just a fat client. But a node that is boot strapping is not a fat client, nor will be me a
member according to isMember().
> I'm also a bit scared of, even in the case of there not being a fat client identification,
simply forgetting an endpoint. It seems that an operator request should be relied upon to
actively forget an endpoint (i.e., forced remove token).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message