cassandra-commits mailing list archives

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


Peter Schuller commented on CASSANDRA-3895:

So I talked to Chris and he seemed to agree with you. But I just have trouble getting it.
Here is the code from Gossiper (the version from the parent ticket):

            if ( epState != null )
                long duration = now - epState.getUpdateTimestamp();

                // check if this is a fat client. fat clients are removed automatically from
                // gossip after FatClientTimeout.  Do not remove dead states here.
                if (!isDeadState(epState) && !epState.isAlive() && !StorageService.instance.getTokenMetadata().isReadEligibleMember(endpoint)
&& !justRemovedEndpoints.containsKey(endpoint) && (duration > FatClientTimeout))
          "FatClient " + endpoint + " has been silent for " + FatClientTimeout
+ "ms, removing from gossip");
                    removeEndpoint(endpoint); // will put it in justRemovedEndpoints to respect
quarantine delay
                    evictFromMembership(endpoint); // can get rid of the state immediately

                // check for dead state removal
                long expireTime = getExpireTimeForEndpoint(endpoint);
                if (!epState.isAlive() && (now > expireTime)
                        && (!StorageService.instance.getTokenMetadata().isReadEligibleMember(endpoint)))
                    if (logger.isDebugEnabled())
                        logger.debug("time is expiring for endpoint : " + endpoint + " ("
+ expireTime + ")");

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.

> Gossiper.doStatusCheck() uses isMember() suspiciously
> -----------------------------------------------------
>                 Key: CASSANDRA-3895
>                 URL:
>             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
> 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:!default.jspa
For more information on JIRA, see:


View raw message