incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Ekström <nikl...@sics.se>
Subject Re: Possible issue with read repair?
Date Thu, 11 Oct 2012 15:09:50 GMT
Thanks!


2012-10-11 16:55, Jonathan Ellis skrev:
> https://issues.apache.org/jira/browse/CASSANDRA-4792
>
> On Wed, Oct 10, 2012 at 4:30 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
>> You're both right -- "read repair" as a concept is indeed performed
>> asynchronously, but RowRepairResolver is used for synchronous, high-CL
>> reads as well, which is the code Niklas is referring to.
>>
>> Niklas, can you create a ticket to fix this officially?
>>
>> On Wed, Oct 10, 2012 at 3:31 PM, Mikhail Panchenko <m@mihasya.com> wrote:
>>> I'll take a stab:
>>>
>>> Without looking at the code, that seems perfectly fine - the purpose of
>>> read repair is to repair potentially stale data out of band. It is
>>> acceptable (from the viewpoint of the datastore) to have "stale" reads
>>> while read-repair happens in the background. Once the repair is completed,
>>> future reads will have the correct data ("eventually"). Reads do not and
>>> should not block on read repair tasks. See
>>> http://www.datastax.com/docs/1.1/cluster_architecture/about_client_requests#about-read-requestsfor
>>> more info.
>>>
>>> In order to achieve what you're looking for and eliminate the window you
>>> are describing, one would write and read at QUORUM consistency level.
>>>
>>> On Wed, Oct 10, 2012 at 1:25 PM, Niklas Ekström <niklase@sics.se> wrote:
>>>
>>>> Hi,
>>>>
>>>> I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766
>>>> seems odd to me.
>>>>
>>>> FBUtilities.waitOnFutures() is called with the repairResults from the
>>>> RowRepairResolver resolver.
>>>>
>>>> The problem though is that repairResults is only assigned when the object
>>>> is created at line 737 in StorageProxy.java, and there it is assigned to
>>>> Collections.emptyList(), and in the resolve() method in RowRepairResolver,
>>>> which is indirectly called from line 771 in StorageProxy.java, that is,
>>>> after the call to FBUtilities.waitOnFutures().
>>>>
>>>> So the effect is that line 766 in StorageProxy.java is essentially a no-op.
>>>>
>>>> If on the other hand line 766 is moved down to just below the try-catch
>>>> block under it (to line 777), the effect of the call to
>>>> FBUtilities.waitOnFutures() would be to wait for responses to the
>>>> READ_REPAIR message. Not waiting for responses to read repair messages
>>>> opens a window of time in which stale reads can happen.
>>>>
>>>> Does this sound reasonable or am I overlooking something?
>>>>
>>>> Regards,
>>>> Niklas
>>>>
>>
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder of DataStax, the source for professional Cassandra support
>> http://www.datastax.com
>
>


Mime
View raw message