[
https://issues.apache.org/jira/browse/CASSANDRA-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105950#comment-13105950
]
Sylvain Lebresne commented on CASSANDRA-3085:
---------------------------------------------
bq. but I still can't see why the old code would cause errors
I don't think it was, the report of this issue is not totally correct, but the
code was fairly ugly: badly encapsulated and potentially more inefficient that
it needs to.
bq. StreamingOutSession.close() calls releaseReference() without
acquireReference(), would that cause a problem ? similar calls are
StreamingOut.createPendingFiles() , StreamingOutSession.startNext()
It's not a problem because those releaseReference calls do are paired with
acquireReference calls (or rather they are supposed to be and last time I
checked all seemed ok). The only thing is that in that case, the
acquireReference calls are unfortunately not near (from a code point of view)
to their paired releaseReference. But we have no choice with how the code of
streaming is structured right now. Typically for a streamOutSession, references
are acquired in either StreamingRepairTask or StreamOut.transferRanges and
released as soon as the sstable is not needed, that is either in
createPendingFiles() if it happens the sstable has none of the ranges we want
to stream or in next()/close() when the sstable has been fully streamed (and
thus won't been accessed by this streamOutSession).
The only small annoying thing with Streaming is that since acquire/release is
not enclosed within a try ... finally block, we could leave a sstable marked
forever if an error occurs during streaming. CASSANDRA-3112 includes code that
would basically allow to deal with this.
> 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
