[
https://issues.apache.org/jira/browse/CASSANDRA-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14537355#comment-14537355
]
Aleksey Yeschenko commented on CASSANDRA-9299:
----------------------------------------------
Attached three patches - for 2.0, 2.1, and trunk, respectively, and pushed to
three branches for cassci to do its thing later:
- https://github.com/iamaleksey/cassandra/commits/9299-2.0
- https://github.com/iamaleksey/cassandra/commits/9299-2.1
- https://github.com/iamaleksey/cassandra/commits/9299-trunk
The 2.0 patch is the most conservative and changes as little as possible - the
only correction there is that cells shadowed by a range tombstone or a
partition tombstone won't count towards the warning and the exception.
So removing a whole partition of cells in one go, or removing a map with 100k
elements, will no longer trigger TOE.
The 2.1 patch goes slightly further, and short-circuits
{{SliceQueryFilter.collectReducedColumns()}} logic if we stumble upon a
tombstone past its gc grace, or, say, an expired TTL column with gc grace for
the table set to 0.
The trunk patch goes slightly further still and gets rid of one redundant
column tester pass over the range tombstones in
{{container.maybeAppendColumn()}} call, relying instead on the result of the
{{columnCounter.count()}} test.
> Fix counting of tombstones towards TombstoneOverwhelmingException
> -----------------------------------------------------------------
>
> Key: CASSANDRA-9299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9299
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 2.1.x, 2.0.x
>
> Attachments: 9299-2.0.txt, 9299-2.1.txt, 9299-trunk.txt
>
>
> CASSANDRA-6042 introduced warning on too many tombstones scanned, then
> CASSANDRA-6117 introduced a hard TombstoneOverwhelmingException condition.
> However, at least {{SliceQuerFilter.collectReducedColumn()}} seems to have
> the logic wrong. Cells that are covered by a range tombstone or a partition
> high level deletion, still count towards {{ColumnCounter}}'s {{ignored}}
> register.
> Thus it's possible to have an otherwise healthy (though large) dropped
> partition read cause an exception that shouldn't be there.
> The only things that should count towards the exception are cell tombstones
> and range tombstones (CASSANDRA-8527), but never ever live cells shadowed by
> any kind of tombstone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
