[jira] [Commented] (CASSANDRA-9684) Update Counter after delete will make counter increments from Previous Counter Values.

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

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

Aleksey Yeschenko commented on CASSANDRA-9684:
----------------------------------------------

Your gc grace seconds is too low (1 second).

In general, you should not reuse the same counters if you delete them at all. Or you should not delete them, at all.

If you do delete then reuse, you will see undefined behaviour with low gc grace seconds, just because deletion doesn't commute with increments.

> Update Counter after delete will make counter increments from Previous Counter Values.
> --------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9684
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9684
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: vinoth
>
> I am using apache-cassandra 2.1.7 datastax version
> I saw the discussion about the counter deletes in CASSANDRA-7326 and CASSANDRA-6532.
> Below is my Case:
> * Create a table with 3 counters with grace_seconds to 1.
> * Update a value to 3 counter.(cnt1+1, cnt2+2,cnt3+3)
> * Now we have some values in 3 counter say (1,2,3)
> * Now i delete the row of counters and i make sure it is flush and compacted.
> * Then update the same query (cnt1+1, cnt2+2,cnt3+3).
>   But the values updated are (2,4,6)-->Previous Counter Values + Current increments.
> cqlsh:pidb> describe table testc;
> CREATE TABLE pidb.testc (
>     domain text PRIMARY KEY,
>     fair counter,
>     good counter,
>     poor counter
> ) WITH bloom_filter_fp_chance = 0.01
>     AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
>     AND comment = ''
>     AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'}
>     AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
>     AND dclocal_read_repair_chance = 0.1
>     AND default_time_to_live = 0
>     AND gc_grace_seconds = 1
>     AND max_index_interval = 2048
>     AND memtable_flush_period_in_ms = 0
>     AND min_index_interval = 128
>     AND read_repair_chance = 0.0
>     AND speculative_retry = '99.0PERCENTILE';
> cqlsh:pidb> select * from testc;
>  domain | fair | good | poor
> --------+------+------+------
>     xyz |   43 |   19 |    9
> [root@node1 ~]# /usr/local/cassandra/bin/nodetool flush
> [root@node1 ~]# /usr/local/cassandra/bin/nodetool compact pidb testc
> psmart@cqlsh:pidb> delete from testc where domain='sbc';
> psmart@cqlsh:pidb> select * from testc;
>  domain | fair | good | poor
> --------+------+------+------
> [root@node1 ~]# /usr/local/cassandra/bin/nodetool flush
> [root@node1 ~]# /usr/local/cassandra/bin/nodetool compact pidb testc
> psmart@cqlsh:pidb> select * from testc;
>  domain | fair | good | poor
> --------+------+------+------
> (0 rows)
> cqlsh:pidb> update testc set poor=poor + 2,good = good +4 , fair = fair+9 where domain='sbc';
> psmart@cqlsh:pidb> select * from testc;
>           (43+9)  (19+4)  (9+2)   
>  domain | fair | good | poor
> --------+------+------+------
>     xyz |   52 |   23 |   11
> Please apologize me if this is already Resolved :)



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