cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3085) Race condition in sstable reference counting
Date Fri, 16 Sep 2011 08:41:08 GMT


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:
>             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