Sylvain Lebresne created CASSANDRA-9655:
-------------------------------------------
Summary: Consider reverting CASSANDRA-7801
Key: CASSANDRA-9655
URL: https://issues.apache.org/jira/browse/CASSANDRA-9655
Project: Cassandra
Issue Type: Bug
Reporter: Sylvain Lebresne
Fix For: 2.1.x
Quoting myself from CASSANDRA-9649:
{quote}
Due to the conjonction of CASSANDRA-7801 and CASSANDRA-5667, if a node has its
clock in the future, other nodes might "synchronize" themselves on that clock
through Paxos operations. While this is probably ok for small drift (this may
even be considered a good thing), this could be rather problematic if a node
ends up with a clock far in the future (even temporarily, due to an operator
error for instance). This is a risk for our Paxos by design, but CASSANDRA-7801
makes the consequences potentially affect other operation as well. This makes
me nervous and while I still think CASSANDRA-7801 is theoretically a good idea,
I'm starting to think that it might not be worth the risk and so I wanted to
float the idea of reversing it.
{quote}
And when I say "revert", I'm talking of committing something like
[this|https://github.com/pcmanus/cassandra/commit/6ad4bbd3e8bfc968e58a44a23b2435a9b41f7cff]
(which is on top of CASSANDRA-9649).
I'll note that an alternative to "reverting" CASSANDRA-7801 could be to rely on
CASSANDRA-6680, that is rely on detecting big clock skew and not starting
up/crashing in that case, thus working around the potential problem. That said,
while we definitively should implement CASSANDRA-6680, I'm not sure how much
we're willing to strongly rely on it to protect us, and hence reverting
CASSANDRA-7801 could still be the safe option even with CASSANDRA-6680.
I'm personally conflicted on what is the best course of action: I do think
CASSANDRA-7801 is a nice to have so I'm tempted to keep it in provided we
prioritize CASSANDRA-6680 somewhat, but I also don't fully trust the latter to
be a bullet proof protection. Thus my asking of other opinions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
