[ 
https://issues.apache.org/jira/browse/CASSANDRA-8383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232824#comment-14232824
 ] 

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: https://issues.apache.org/jira/browse/CASSANDRA-8383
>             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
(v6.3.4#6332)

Reply via email to