cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-3145) IntervalTree could miscalculate its max
Date Tue, 06 Sep 2011 22:15:10 GMT


paul cannon updated CASSANDRA-3145:

    Attachment: 3145.patch.txt

fixes IntervalTree.max calculation.

also eliminates a small amount of overhead for the use of a ConcurrentSkipListSet, since there
isn't a need for the efficient contains/remove operations or the concurrency support.

> IntervalTree could miscalculate its max
> ---------------------------------------
>                 Key: CASSANDRA-3145
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: paul cannon
>            Assignee: paul cannon
>            Priority: Minor
>             Fix For: 1.0
>         Attachments: 3145.patch.txt
> The implementation of IntervalTree in trunk expects an ordered list of Interval objects
as the argument to its constructor. It uses the ordering (only) to determine its minimum and
maximum endpoints out of all Intervals stored in it. However, no ordering should be able to
guarantee the first element has the set-wide minimum and that the last element has the set-wide
maximum; you have to order by minima or maxima or some combination.
> I propose that the requirement for ordered input to the IntervalTree constructor be dropped,
seeing as how the elements will be sorted as necessary inside the IntervalNode object anyway.
The set-wide minimum and maximum could be more straightforwardly calculated inside IntervalNode,
and just exposed via IntervalTree.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message