[
https://issues.apache.org/jira/browse/CASSANDRA-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne reopened CASSANDRA-2641:
-----------------------------------------
Sorry, I was much too quick in reviewing this. The patch has two problems:
* It works only for Bounds, not Range. It will say that (1, 2] and (2, 3] are
overlapping but it's not.
* It does the check on the unsorted input list, so that's another reason why
he will uncorrectly report overlapping
Because I'm stubborn, I'm attaching a patch that take the approach of making
normalize() deoverlap overlapping ranges. It also add a number of unit tests
for normalize.
> AbstractBounds.normalize should deal with overlapping ranges
> ------------------------------------------------------------
>
> Key: CASSANDRA-2641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2641
> Project: Cassandra
> Issue Type: Test
> Components: Core
> Reporter: Stu Hood
> Assignee: Stu Hood
> Priority: Minor
> Fix For: 0.8.1
>
> Attachments: 0001-Assert-non-overlapping-ranges-in-normalize.txt,
> 0001-Make-normalize-deoverlap-ranges.patch,
> 0002-Don-t-use-overlapping-ranges-in-tests.txt
>
>
> Apparently no consumers have encountered it in production, but
> AbstractBounds.normalize does not handle overlapping ranges. If given
> overlapping ranges, the output will be sorted but still overlapping, for
> which SSTableReader.getPositionsForRanges will choose ranges in an SSTable
> that may overlap.
> We should either add an assert in normalize(), or in getPositionsForRanges()
> to ensure that this never bites us in production.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
