[
https://issues.apache.org/jira/browse/CASSANDRA-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092928#comment-13092928
]
Sylvain Lebresne commented on CASSANDRA-3085:
---------------------------------------------
* The try of the try...finally block should start just after the markReferenced
to be safe in CollationControler.
* In CFS.getRangeSlice, I am not confortable using the same try...finally block
for both the view and the iterator. RowIteratorFactory.getIterator() does make
seeks and could throw an error that would leave a bunch of sstable referenced.
* Nit: Maybe we could use a plain old DataTracker.View instead of introducing
ViewFragment, since the View constructor is accessible to CFS anyway ?
> 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
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Critical
> Fix For: 1.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
