You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/07/16 02:41:14 UTC
[jira] Resolved: (CASSANDRA-286) slice offset breaks read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-286.
--------------------------------------
Resolution: Fixed
committed
> slice offset breaks read repair
> -------------------------------
>
> Key: CASSANDRA-286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-286
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Attachments: 0001-CASSANDRA-286-r-m-offset-from-slice-api-we-could-live.txt, 0002-fix-not-including-tombstone-only-keys-in-keyRange.txt
>
>
> [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.