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

Aleksey Yeschenko commented on CASSANDRA-9299:
----------------------------------------------

Why I think the change is justified: the purpose of CASSANDRA-6042 and later 
CASSANDRA-6117 was to help us avoid OOMs in scenarios where we have to scan 
through *and accumulate* cells that aren't live - to do a digest of them, or to 
return them to a coordinator, or to return them to a client. It only makes 
sense that cells that don't get retained in memory for those actions to happen 
should not count towards the exception.

It could be said that extra scanning also causes issues for the client, and 
that's true, but it is a different issue, and should be handled in a separate 
ticket. Additionally, all redundantly read cells should be counted for that 
purpose - shadowed by partition tombstone, overwritten by a newer live cell, 
etc.

The current counting logic is a mix of both of these, and does counting either 
badly, and must be split.

> 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)

Reply via email to