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

Peter Schuller edited comment on CASSANDRA-3895 at 2/13/12 2:29 AM:
--------------------------------------------------------------------

{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 INVALID then, though I'm skeptical about the 3 day very 
long time.

                
      was (Author: scode):
    {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

        

Reply via email to