[
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
