[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock
[ https://issues.apache.org/jira/browse/CASSANDRA-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-11991: - Labels: LWT (was: ) > On clock skew, paxos may "corrupt" the node clock > - > > Key: CASSANDRA-11991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11991 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Major > Labels: LWT > Fix For: 2.1.15, 2.2.7, 3.0.8, 3.8 > > > W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node > can "corrupt" other node clocks through Paxos. That wasn't intended and we > should fix that. I'll attach a patch later. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock
[ https://issues.apache.org/jira/browse/CASSANDRA-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-11991: - Resolution: Fixed Fix Version/s: (was: 3.0.x) (was: 2.2.x) (was: 2.1.x) 3.0.8 3.8 2.2.7 2.1.15 Status: Resolved (was: Patch Available) Committed, thanks. > On clock skew, paxos may "corrupt" the node clock > - > > Key: CASSANDRA-11991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11991 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 2.1.15, 2.2.7, 3.8, 3.0.8 > > > W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node > can "corrupt" other node clocks through Paxos. That wasn't intended and we > should fix that. I'll attach a patch later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock
[ https://issues.apache.org/jira/browse/CASSANDRA-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-11991: -- Reviewer: Jason Brown (was: sankalp kohli) > On clock skew, paxos may "corrupt" the node clock > - > > Key: CASSANDRA-11991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11991 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 2.1.x, 2.2.x, 3.0.x > > > W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node > can "corrupt" other node clocks through Paxos. That wasn't intended and we > should fix that. I'll attach a patch later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock
[ https://issues.apache.org/jira/browse/CASSANDRA-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-11991: - Status: Patch Available (was: Open) For context, the problem is basically the one I described in [my comment|https://issues.apache.org/jira/browse/CASSANDRA-9649?focusedCommentId=14601016&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601016] on CASSANDRA-9649 and for which I suggested reverting CASSANDRA-7801. Now, I was kind of wrong about reverting CASSANDRA-7801 since since CASSANDRA-9649 we were relying on {{ClientState.getTimestamp()}} to give use timestamp that were unique for the running VM, which meant we can't blindly revert CASSANDRA-7801. What I think is the simplest solution however is to stop relying on that property (of {{ClientState.getTimestamp()}}) for the uniqueness of our ballots, but instead randomize the non-timestamp parts of the ballot for every new ballot. With that, we don't have to revert CASSANDRA-7801, we just have to ensure that if we use the last known proposal timestamp (i.e. if whomever clock generated that timestamp is "in the future"), we don't persist it in the local clock (this in turn means the timestamp might not be unique in the VM for 2 concurrent paxos operation and hence the need to randomize the rest of the UUID). I've pushed a patch for this for 2.1. I'll attach branches for 2.2+ with tests tomorrow (but was waiting on the 2.1 results before doing that) but I don't think the modified code has changed since 2.1 so marking ready for review in the meantime. | [2.1|https://github.com/pcmanus/cassandra/commits/11991-2.1] | [utests|http://cassci.datastax.com/job/pcmanus-11991-2.1-testall/] | [dtests|http://cassci.datastax.com/job/pcmanus-11991-2.1-dtest/] | > On clock skew, paxos may "corrupt" the node clock > - > > Key: CASSANDRA-11991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11991 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 2.1.x, 2.2.x, 3.0.x > > > W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node > can "corrupt" other node clocks through Paxos. That wasn't intended and we > should fix that. I'll attach a patch later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock
[ https://issues.apache.org/jira/browse/CASSANDRA-11991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sankalp kohli updated CASSANDRA-11991: -- Reviewer: sankalp kohli > On clock skew, paxos may "corrupt" the node clock > - > > Key: CASSANDRA-11991 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11991 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne > Fix For: 2.1.x, 2.2.x, 3.0.x > > > W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node > can "corrupt" other node clocks through Paxos. That wasn't intended and we > should fix that. I'll attach a patch later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)