[ 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