[
https://issues.apache.org/jira/browse/CASSANDRA-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729306#action_12729306
]
Jonathan Ellis commented on CASSANDRA-286:
------------------------------------------
Yes, that's the brute force fix, but it means that in the case of mass deletes
in a given CF we could very possibly OOM collecting all the tombstones for a
large offset.
Again, my rule of thumb is: features that allow the user to do something that
slow things down are ok; features that allow the user to crash the server, are
not. :)
> slice offset breaks read repair
> -------------------------------
>
> Key: CASSANDRA-286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-286
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
>
> [code]
> int liveColumns = 0;
> int limit = offset + count;
> for (IColumn column : reducedColumns)
> {
> if (liveColumns >= limit)
> break;
> if (!finish.isEmpty()
> && ((isAscending && column.name().compareTo(finish) > 0))
> || (!isAscending && column.name().compareTo(finish) < 0))
> break;
> if (!column.isMarkedForDelete())
> liveColumns++;
> if (liveColumns > offset)
> returnCF.addColumn(column);
> }
> [code]
> The problem is that for offset to return the correct "live" columns, it has
> to ignore tombstones it scans before the first live one post-offset.
> This means that instead of being corrected within a few ms of a read, a node
> can continue returning deleted data indefinitely (until the next anti-entropy
> pass).
> Coupled with offset's inherent inefficiency (see CASSANDRA-261) I think this
> means we should take it out and leave offset to be computed client-side
> (which, for datasets under which it was reasonable server-side, will still be
> reasonable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
