cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2641) AbstractBounds.normalize should deal with overlapping ranges
Date Thu, 12 May 2011 10:34:47 GMT


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

View raw message