[
https://issues.apache.org/jira/browse/CASSANDRA-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032346#comment-13032346
]
Sylvain Lebresne commented on CASSANDRA-2641:
---------------------------------------------
bq. 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.
Yes, you're right. Anyway we never generate overlapping ranges, so I'm pretty
sure it hasn't bitten anyone for good reason. Nevertheless, I do agree that it
is worth protecting ourselves. I still have a preference for making normalize()
merge intersecting ranges (it makes sense a "normalize" function would do that
and it's fairly trivial).
> 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
