[jira] [Commented] (CASSANDRA-11166) Range tombstones not accounted in tracing/cfstats

["Anubhav Kale (JIRA)" <ji...@apache.org>]

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

Anubhav Kale commented on CASSANDRA-11166:
------------------------------------------

Thanks for the update. 

Based on the code in SliceQueryFilter (2.1.9 Tag) where the TombstoneoverwhelmingException is thrown, it appears that range tombstones don't contribute to this counting. Is this the expected behavior (seems wrong to me) ? So, I am not sure if this is just a logging issue or has more implications.

> Range tombstones not accounted in tracing/cfstats
> -------------------------------------------------
>
>                 Key: CASSANDRA-11166
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11166
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Anubhav Kale
>            Priority: Minor
>
> I noticed an inconsistent behavior on deletes. Not sure if it is intentional. 
> The summary is:
> If a table is created with TTL or if rows are inserted in a table using TTL, when its time to expire the row, tombstone is generated (as expected) and cfstats, cqlsh tracing and sstable2json show it.
> However, if one executes a delete from table query followed by a select *, neither cql tracing nor cfstats shows a tombstone being present. However, sstable2json shows a tombstone.
> Is this situation treated differently on purpose ? In such a situation, does Cassandra not have to scan tombstones (seems odd) ?
> Also as a data point, if one executes a delete <some-column> from table, cqlsh tracing, nodetool cfstats, and sstable2json all show a consistent result (tombstone being present).
> As a end user, I'd assume that deleting a row either via TTL or explicitly should show me a tombstone. Is this expectation reasonable ? If not, can this behavior be clearly documented ?



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