[
https://issues.apache.org/jira/browse/CASSANDRA-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14170223#comment-14170223
]
Brandon Williams commented on CASSANDRA-8113:
---------------------------------------------
bq. when we do detect a peer with a bad version value, I chose to not log it as
I assume the bad value will continue to be sent by the bad peer(s), and we'll
start filling up the log with the same redundant message. Should we log it?
I think we should, because it would be difficult to diagnose the case of one
machine with a borked clock not showing up without the log to indicate the
problem.
bq. I'm assuming that we can't trust the peer who sent the bad version, and
shouldn't take action to mark the indicated node alive based upon the borked
peer's incorrect version value.
I agree.
> Gossip should ignore generation numbers too far in the future
> -------------------------------------------------------------
>
> Key: CASSANDRA-8113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8113
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Richard Low
> Assignee: Jason Brown
> Attachments: 8113-v1.txt
>
>
> If a node sends corrupted gossip, it could set the generation numbers for
> other nodes to arbitrarily large values. This is dangerous since one bad node
> (e.g. with bad memory) could in theory bring down the cluster. Nodes should
> refuse to accept generation numbers that are too far in the future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)