[
https://issues.apache.org/jira/browse/CASSANDRA-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206623#comment-13206623
]
Brandon Williams commented on CASSANDRA-3895:
---------------------------------------------
bq. Are you saying it is, by definition? If so I don't understand it at all.
In terms of membership, a fat client is any node that participates in gossip
but is not a ring member.
bq. So we have two distinct checks; one claims to be removing a fat client,
while the other is just expiring it silently (unless debug is enabled). So what
is the reason for the distinction? And the fat client timeout is different from
the expiration timeout.
The distinction is, the first check which claims to be removing fat clients is
doing just that, while the second is removing _dead states_, such as a node
that was removed. Dead states are held longer because if the cluster is
partitioned, it is important for the dead state to be propagated when the
partition heals. If fat clients disappear, no one really cares because they
were never ring members.
> 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
