[jira] [Updated] (CASSANDRA-3145) IntervalTree could miscalculate its max

["paul cannon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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: https://issues.apache.org/jira/browse/CASSANDRA-3145
>             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: http://www.atlassian.com/software/jira