[jira] [Updated] (CASSANDRA-6692) AtomicBTreeColumns Improvements

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

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

Benedict updated CASSANDRA-6692:
--------------------------------

    Attachment: 6692.fix

Hmm. This actually exposed a bug we already had: reuse of the ThreadLocal cached instance of the BTree.Builder, through nested BTree updates. This basically completely breaks everything with SecondaryIndex updates, as we apply the SI update whilst performing the BTree.update(). I've converted the ThreadLocal to a queue instead of an instance.

Investigating this I also exposed another bug in the same area, with CASSANDRA-6655, where we would lose topLevel deletionInfo. I've included the fix for that in the attached patch.

> AtomicBTreeColumns Improvements
> -------------------------------
>
>                 Key: CASSANDRA-6692
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6692
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: easyfix, performance
>             Fix For: 2.1 beta2
>
>         Attachments: 6692.fix
>
>
> There are two improvements to make to the BTree code that should help:
> 1) It turns out Stack Allocation is more rubbish than we had hoped, and so the fast route actually allocates garbage. It's unlikely this reduces throughput, but the increased young-gen pressure is probably unwelcome. I propose to remove the fast route for now.
> 2) It is not uncommon to race to perform an update, so that the new values are actually out-of-date when we come to modify the tree. In this case the update should recognise that the original (portion of) the tree has not been modified, and simply return it, without allocating a new one.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)