cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3085) Race condition in sstable reference counting
Date Fri, 16 Sep 2011 07:35:09 GMT

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

Yang Yang commented on CASSANDRA-3085:
--------------------------------------


bq.  Not so – you're missing the "this sstable is compacted and is obsolete" release done
by DataTracker.


do you mean this part in DataTracker ? (line 262)

    private void replace(Collection<SSTableReader> oldSSTables, Iterable<SSTableReader>
replacements)
    {
        View currentView, newView;
        do
        {
            currentView = view.get();
            newView = currentView.replace(oldSSTables, replacements);
        }
        while (!view.compareAndSet(currentView, newView));

        addNewSSTablesSize(replacements);
        removeOldSSTablesSize(oldSSTables); //<==== this calls releaseReference() 

        notifySSTablesChanged(replacements, oldSSTables);
        cfstore.updateCacheSizes();
    }

the SSTableReaders which do a releaseReference() are all in the "oldSSTables" set, the newView
takes out all the oldSSTables in the newView computation. Since the view change is done atomically
in view.compareAndSet(), each SSTableReader can invoke the releaseReference() only once in
this path, since once it's called releaseReference(), it must have been removed from the view.

so, for this path, each SSTableReader can invoke the releaseReference() once in its life time.
that's what I   mean: you can "view" the compaction path as  doing  a "+" at the construction
of SSTableReader, and doing a corresponding "-" at the code above.


also 
StreamingOutSession.close() calls releaseReference() without acquireReference(), would that
cause a problem ? similar calls are StreamingOut.createPendingFiles() , StreamingOutSession.startNext()


Thanks a lot for your patience, please pardon my numerous questions, I just want to make sure
that I thoroughly understand it and there are no hidden issues.


> Race condition in sstable reference counting
> --------------------------------------------
>
>                 Key: CASSANDRA-3085
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3085
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.0
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Critical
>             Fix For: 1.0.0
>
>         Attachments: 3085-v2.txt, 3085.txt
>
>
> DataTracker gives us an atomic View of memtable/sstables, but acquiring references is
not atomic.  So it is possible to acquire references to an SSTableReader object that is no
longer valid, as in this example:
> View V contains sstables {A, B}.  We attempt a read in thread T using this View.
> Meanwhile, A and B are compacted to {C}, yielding View W.  No references exist to A or
B so they are cleaned up.
> Back in thread T we acquire references to A and B.  This does not cause an error, but
it will when we attempt to read from them next.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message