[jira] [Commented] (CASSANDRA-14462) CAS temporarily broken on reversed tables after upgrading on 2.1.X or 2.2.X

["Fabien Rousseau (JIRA)" <ji...@apache.org>]

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

Fabien Rousseau commented on CASSANDRA-14462:
---------------------------------------------

I propose the following patch.

It works with the scenario described in the ticket.

This might not be the right way to fix the issue, but it has the advantage of being rather simple and safe, at the expense of a performance penalty before scrubbing. (Once scrubbed, there is no more penalty).

The patch works by disabling the min/max column check for tables with a clustering key and for the first clustering component being a reversed comparator (and automatically including it).

There are no unit tests because I don't know how to automatically generate SSTable of a previous version then use them (but please let me know if it is possible).

 

Note: the patch is simple enough to apply cleanly to both 2.1 & 2.2 branches.

> CAS temporarily broken on reversed tables after upgrading on 2.1.X or 2.2.X
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-14462
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14462
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Fabien Rousseau
>            Priority: Major
>         Attachments: 14662-2.1-2.2.patch
>
>
> Issue CASSANDRA-12127 changed the way the reversed comparator behaves. Before scrubbing tables with reversed clustering keys, requests with CAS won't apply (even if the condition is true).
> Below is a simple scenario to reproduce it:
> - use C* 2.1.14/2.2.6
> - create the schema
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS test_ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
> USE test_ks;
> CREATE TABLE IF NOT EXISTS test_cf (
>  pid text,
>  total int static,
>  sid uuid,
>  amount int,
>  PRIMARY KEY ((pid), sid)
> ) WITH CLUSTERING ORDER BY (sid DESC);
> {code}
>  
> - insert data
> {code:java}
> INSERT INTO test_cf (pid, sid, amount) VALUES ('1', b2495ad2-9b64-4aab-b000-2ed20dda60ab, 2);
> INSERT INTO test_cf (pid, total) VALUES ('1', 2);{code}
>  
> - nodetool flush (this is necessary for the scenario to show the problem)
> - upgrade to C* 2.1.20/2.2.12
> - execute the following queries:
> {code:java}
> UPDATE test_cf SET total = 3 WHERE pid = '1' IF total = 2;
> UPDATE test_cf SET amount = 3 WHERE pid = '1' AND sid = b2495ad2-9b64-4aab-b000-2ed20dda60ab IF amount = 2;{code}
>  
> Both statements won't be applied while they should be applied.
> It seems related to the min/maxColumn sstable checks (before the scrubbing, the min is an empty array, after it is no more) which filter too many sstables.
> The SliceQueryFilter.shouldInclude method filter too many SSTables.
> Note: When doing a simple "SELECT total FROM test_cf WHERE pid ='1';" works well because the selected slices are different (and thus do not filter the sstables).
> Note: This does not seem to affect the 3.0.X versions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org