[
https://issues.apache.org/jira/browse/CASSANDRA-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309166#comment-14309166
]
Marcus Eriksson commented on CASSANDRA-8707:
--------------------------------------------
bq. It would be helpful if, once I've introdiced a high-level overview, the
individuals familiar with the tool or special compaction lifecycles (or others)
could amend the SSTableReader description
Absolutely, for now I think that a concrete explanation of what happens to an
sstable that is early opened and one that is cloneWithNewStart(..):ed is enough
bq. Could you list the places you think need this service? Since the code
outside of SSTableReader tidying is largely functionally unchanged
I don't think *I* need the service, it is mostly to avoid future confusion, and
I figured now was a good time to clear up the confusing bits since we are
touching those code parts (when would we do that otherwise?). I know most of
the code was just moved around from other places and it was terrible before
this, but that doesn't really stop us from making it easier for the future.
I just want a small 'why' instead of a comment stating the obvious:
{code}
// we don't want to alert deletions if not final
{code}
{code}
// get a new reference to the shared descriptor-type tidy
{code}
Those are just two examples, once the life cycle description is done, I can add
the comments about the details I found confusing
> Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted
> ------------------------------------------------------------------------
>
> Key: CASSANDRA-8707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8707
> Project: Cassandra
> Issue Type: Bug
> Reporter: Benedict
> Assignee: Benedict
> Priority: Critical
> Fix For: 2.1.3
>
>
> There are still a few bugs with resource management, especially around
> SSTableReader cleanup, esp. when intermixing with compaction. This migration
> should help. We can simultaneously "simplify" the logic in SSTableReader to
> not track the replacement chain, only to take a new reference to each of the
> underlying resources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
