[
https://issues.apache.org/jira/browse/CASSANDRA-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309098#comment-14309098
]
Benedict commented on CASSANDRA-8707:
-------------------------------------
bq. Also, I think we need some high level documentation with concrete examples
about the life cycle of sstables. ... (perhaps as a big comment on top in
SSTableReader?)
This seems like an excellent idea, and this ticket seems like a good
opportunity to introduce it, although it will have to be revised with each of
my follow ons. It didn't really occur to me to do this since that is all
unchanged here, but it has grown overtime to be very non-obvious. 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 to make it clear how they are expected to
behave and treat sstables, and what assumptions they utilise, as that is often
subtly different and I am not at all an expert in those areas.
bq. I think the penny has finally dropped for me, the thing I'm missing now is
more "why?"-comments, for example, why do we need to copy CompressionMetadata
in CM.Writer#open(..) if finish type is final and not otherwise?
Could you list the places you think need this service? Since the code outside
of SSTableReader tidying is largely functionally unchanged, only swapping in a
new API, it's not clear which bits need this, outside of the high level
overview. This particular spot, for instance, had this behaviour previously
(and it's about resizing, rather than copying, since we now know the final size
of the data so can release it). One of the follow tickets also cleans this
particular spot up a little, by introducing an enum specific to it that
describes the reasons for opening (which should make that more obvious). I'm
hoping a small follow up I've yet to publish will also simplify that particular
bit further. I'm more than happy to flesh out comments, but would appreciate an
outline of which bits you think have been lacking historically.
> 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)
