[ https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984553#comment-15984553 ]
Andrés de la Peña commented on CASSANDRA-8272: ---------------------------------------------- And [here are the dtests|https://github.com/riptano/cassandra-dtest/compare/master...adelapena:CASSANDRA-8272] reproducing the problem. They use 2 replicas instead of 3. Updates use consistency {{ONE}}, and byteman is used in one of the two nodes to simulate a long latency during index updates. Insertions and selections use consistency {{ALL}}. Cassandra 2.1 doesn't use byteman so, if we are going to fix this version, we could either add the byteman dependency to 2.1 or modify [the way ccm loads the byteman jars|https://github.com/pcmanus/ccm/blob/master/ccmlib/node.py#L1609]. > 2ndary indexes can return stale data > ------------------------------------ > > Key: CASSANDRA-8272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8272 > Project: Cassandra > Issue Type: Bug > Reporter: Sylvain Lebresne > Assignee: Andrés de la Peña > Fix For: 2.1.x > > > When replica return 2ndary index results, it's possible for a single replica > to return a stale result and that result will be sent back to the user, > potentially failing the CL contract. > For instance, consider 3 replicas A, B and C, and the following situation: > {noformat} > CREATE TABLE test (k int PRIMARY KEY, v text); > CREATE INDEX ON test(v); > INSERT INTO test(k, v) VALUES (0, 'foo'); > {noformat} > with every replica up to date. Now, suppose that the following queries are > done at {{QUORUM}}: > {noformat} > UPDATE test SET v = 'bar' WHERE k = 0; > SELECT * FROM test WHERE v = 'foo'; > {noformat} > then, if A and B acknowledge the insert but C respond to the read before > having applied the insert, then the now stale result will be returned (since > C will return it and A or B will return nothing). > A potential solution would be that when we read a tombstone in the index (and > provided we make the index inherit the gcGrace of it's parent CF), instead of > skipping that tombstone, we'd insert in the result a corresponding range > tombstone. -- This message was sent by Atlassian JIRA (v6.3.15#6346)