Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 2 May 2016 10:26:13 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12753517.1415309029000.84214.1462184773046@Atlassian.JIRA>
In-Reply-To: <JIRA.12753517.1415309029000@Atlassian.JIRA>
References: <JIRA.12753517.1415309029000@Atlassian.JIRA> <JIRA.12753517.1415309029941@arcas>
Subject: [jira] [Commented] (CASSANDRA-8273) Allow filtering queries can
 return stale data
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 02 May 2016 10:26:15 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266352#comment-15266352 ] 

Sylvain Lebresne commented on CASSANDRA-8273:
---------------------------------------------

I don't really understand the reasoning of that. If you can live with stale data, why would you use {{QUORUM}} in the first place? Imo, either we're able to fix this somehow, or we should consider moving filtering coordinator side always. Haven't yet had time to put too much though on how to do the former though so far.

> Allow filtering queries can return stale data
> ---------------------------------------------
>
>                 Key: CASSANDRA-8273
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8273
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>
> Data filtering is done replica side. That means that a single replica with stale data may make the whole query return that stale data.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v1 text, v2 int);
> CREATE INDEX ON test(v1);
> INSERT INTO test(k, v1, v2) VALUES (0, 'foo', 1);
> {noformat}
> with every replica up to date. Now, suppose that the following queries are done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v2 = 2 WHERE k = 0;
> SELECT * FROM test WHERE v1 = 'foo' AND v2 = 1;
> {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. Let's note that this is a problem related to filtering, not 2ndary indexes.
> This issue share similarity with CASSANDRA-8272 but contrarily to that former issue, I'm not sure how to fix it. Obviously, moving the filtering to the coordinator would remove that problem, but doing so would, on top of not being trivial to implmenent, have serious performance impact since we can't know in advance how much data will be filtered and we may have to redo query to replica multiple times.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)