[
https://issues.apache.org/jira/browse/CASSANDRA-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031791#comment-13031791
]
Sylvain Lebresne commented on CASSANDRA-2633:
---------------------------------------------
bq. But I don't see how this affects the C row?
This affects the C row because it will use the position of C found as the
position where to stop scanning. But the position of C is the start of C, so
when used as an end position, it excludes it. That is, getPositionForRanges
will return (start of A, start of C), which results in scanning [A, C) as
Richard says.
So +1 on this.
> Keys get lost in bootstrap
> --------------------------
>
> Key: CASSANDRA-2633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2633
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.5
> Reporter: Richard Low
> Priority: Critical
> Attachments: 0.7-2633.txt, 0001-2633-unit-test.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> When bootstrapping a new node, the key at the upper end of the new node's
> range can get lost. To reproduce:
> * Set up one cassandra node, create a keyspace and column family and perform
> some inserts
> * Read every row back
> * Bootstrap a second node
> * Read every row back
> You find one row is missing, whose row key is exactly equal to the token the
> new node gets (for OPP - for RP it's the key whose hash is equal to the
> token). If you don't do the reads after the inserts, the key is not lost. I
> tracked the problem down to o.a.c.io.sstable.SSTableReader in getPosition.
> The problem is that the cached position is used if it is there (so only if
> the reads were performed). But this is incorrect because the cached position
> is the start of the row, not the end. This means the end row itself is not
> transferred. This causes the last key in the range to get lost.
> Although I haven't seen it, this may occur during antientropy repairs too.
> The attached patch (against the 0.7 branch) fixes it by not using the cache
> for Operator.GT. I haven't tested with 0.8 but from looking at the code I
> think the problem is present.
> This might be related to CASSANDRA-1992
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
