cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-8707) Move SegmentedFile, IndexSummary and BloomFilter to utilising RefCounted
Date Fri, 06 Feb 2015 14:17:35 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309166#comment-14309166
] 

Marcus Eriksson edited comment on CASSANDRA-8707 at 2/6/15 2:16 PM:
--------------------------------------------------------------------

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
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


was (Author: krummas):
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)

Mime
View raw message