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