cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Yang (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3085) Race condition in sstable reference counting
Date Thu, 15 Sep 2011 08:38:09 GMT


Yang Yang commented on CASSANDRA-3085:

Thanks Jonathan.

but I still can't see why the old code would cause errors, could you please see if the following
reason makes sense?

if you look at the operations of +1 and -1 by read paths and the compaction path, either the
read path or the compaction can be seen as the following sequence


//access the SSTableReader


where for the compaction the "+1" happens at creation of the SSTableReader; for read paths
the "+1" happens at acquireReference()

since every path (either compaction or reader) does one +1 and one -1, by the time a path
finishes, the ref count will be equal to the number of live code paths

if the file is removed, the ref count must be 0, hence live paths count at that moment must
be 0. if there are no future paths to run, it's all good. if there are , the path would access
a file already removed and we have a problem. but this is impossible because: if  the +1 comes
after compaction.release(), because compaction.release() comes after the view change in DataTracker.replace(),
then reader path.acquire() comes after DataTracker.replace(),  but this is impossible because
the reader can not see that SSTableReader in its view.

> Race condition in sstable reference counting
> --------------------------------------------
>                 Key: CASSANDRA-3085
>                 URL:
>             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:


View raw message