cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8383) Memtable flush may expire records from the commit log that are in a later memtable
Date Wed, 03 Dec 2014 09:48:12 GMT


Benedict commented on CASSANDRA-8383:

bq. Does this deserve a regression test? 

bq. We should also introduce a commit log correctness stress test, so we can reproduce this,
be certain it is fixed, and so we can be sure to avoid this or similar scenarios in future.

Yes, absolutely. However I have been tasked with other pressing things - I only took time
out to file and address this because it is an obvious and dangerous potential failure of correctness.
We should file a follow up ticket for introducing rigorous randomized testing to tease out
any potential correctness issues from this codepath, which either can be looked at immediately
by somebody else, or I can take a look at once my current workload is dealt with. But doing
this well requires a bit of time and focus, which I didn't want holding up a fix.

> Memtable flush may expire records from the commit log that are in a later memtable
> ----------------------------------------------------------------------------------
>                 Key: CASSANDRA-8383
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Critical
>              Labels: commitlog
>             Fix For: 2.1.3
> This is a pretty obvious bug with any care of thought, so not sure how I managed to introduce
it. We use OpOrder to ensure all writes to a memtable have finished before flushing, however
we also use this OpOrder to direct writes to the correct memtable. However this is insufficient,
since the OpOrder is only a partial order; an operation from the "future" (i.e. for the next
memtable) could still interleave with the "past" operations in such a way that they grab a
CL entry inbetween the "past" operations. Since we simply take the max ReplayPosition of those
in the past, this would mean any interleaved future operations would be expired even though
they haven't been persisted to disk.

This message was sent by Atlassian JIRA

View raw message