[
https://issues.apache.org/jira/browse/CASSANDRA-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032341#comment-13032341
]
Stu Hood commented on CASSANDRA-2641:
-------------------------------------
bq. It's true that overlapping ranges would result in streaming twice the
overlapping sections, but that's an efficiency problem, so I don't think an
assert is the solution.
If getPositionsForRanges generates overlapping ranges in the file, then the
data that is streamed will be out of order and invalid (not to mention the fact
that we wouldn't be doing sequential access). Thankfully, we only seem to have
accidentally used overlapping ranges in tests.
I haven't fully explored it yet, but
StreamTransferTest.testTransferTableMultiple generates overlapping ranges, and
hence invalid output sstables (need to confirm). I think this succeeds in trunk
because the remainder of the file is dead due to the index being out of order,
but it fails in a branch I'm working on (for the same streamed offsets). Will
investigate more tomorrow.
> 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: 1.0
>
>
> 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
