[
https://issues.apache.org/jira/browse/CASSANDRA-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105018#comment-13105018
]
Jonathan Ellis commented on CASSANDRA-3085:
-------------------------------------------
Right. A sstable starts with one reference. When we do a read, we acquire a
reference, then release when we're done. When we compact it, we release a
reference.
So we can do arbitrary numbers of reads w/o reference count getting to zero,
but once we compact, either the compact release or a read release will drop it
to zero. This last release will unmap and delete it, whether from compaction or
a read.
> 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
