[jira] [Updated] (CASSANDRA-6919) Use OpOrder to guard sstable references for reads, instead of acquiring/releasing references

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

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

Jonathan Ellis updated CASSANDRA-6919:
--------------------------------------

    Reviewer: Marcus Eriksson

[~krummas] to review

> Use OpOrder to guard sstable references for reads, instead of acquiring/releasing references
> --------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6919
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6919
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>             Fix For: 2.1 beta2
>
>
> To slightly improve CASSANDRA-6916, and because it's a bit of a simplification anyway, we should move to ensuring sstable resources remain around during reads by guarding them with an OpOrder (which is also being introduced for CASSANDRA-6694) instead of using markReferenced()/release.
> Note this does not eliminate markReferenced, as for long running processes such as compaction it makes sense to have an independent mechanism, because these long running processes would prevent all resource cleanup for their duration rather than just the resources they're using. 
> All this does is cleanup and slightly optimise the read path, whilst giving better guarantees about resource cleanup (e.g. page cache dropping of old sstables which may have been replaced multiple times since the reader was created, so we are dropping pages we don't realise are still in use - in real terms it should be very rare for such a reader to outlive multiple replacements and this is only a performance issue, not a matter of correctness, but it's nice to absolutely be certain anyway).



--
This message was sent by Atlassian JIRA
(v6.2#6252)