[
https://issues.apache.org/jira/browse/CASSANDRA-9932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680956#comment-14680956
]
Benedict commented on CASSANDRA-9932:
-------------------------------------
bq. I ran the long btree test and and testOversizedMiddleInsert failed for me
You need a large heap.
bq. I couldn't find a job running the burn tests. I think we decided against it
because this stuff never changes (oops).
The idea is that you run it for a long time when you do change it. I've run it
locally for a reasonably long time, but it would be nice to leave it running
for a few days somewhere to be sure.
bq. derived classes of ... BTree
Which derived classes, other than BTreeSet? The latter is covered _pretty_
thoroughly by {{LongBTreeTest}}
In general, as much as I'm strongly in favour of introducing more unit tests
here and will aim to do so before release, I don't consider it more important
than getting the foundation for the whole 3.0 line as tight as it can be before
we ship. Far more so than ever, given the manner of recent changes. Testing has
been behind for years, and can easily be improved close to or after GA. Major
(even minor) code refactors cannot unless they fix a sufficiently important
bug, and yet they pay dividends in helping fix those bugs. Working around
structural inadequacy is incredibly challenging, and has been a source of
consistent pain when addressing bugs found in earlier releases
bq. I will try and figure out a way to post it that format well.
Thanks, that would be appreciated. Would be awesome if a score sheet could be
auto-generated for new and modified code (independently).
> Make all partitions btree backed
> --------------------------------
>
> Key: CASSANDRA-9932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9932
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0.0 rc1
>
>
> Following on from the other btree related refactors, this patch makes all
> partition (and partition-like) objects backed by the same basic structure:
> {{AbstractBTreePartition}}. With two main offshoots:
> {{ImmutableBTreePartition}} and {{AtomicBTreePartition}}
> The main upshot is a 30% net code reduction, meaning better exercise of btree
> code paths and fewer new code paths to go wrong. A secondary upshort is that,
> by funnelling all our comparisons through a btree, there is a higher
> likelihood of icache occupancy and we have only one area to focus delivery of
> improvements for their enjoyment by all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
