Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 8 Feb 2017 12:10:41 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13029803.1482336131000.28402.1486555841776@Atlassian.JIRA>
In-Reply-To: <JIRA.13029803.1482336131000@Atlassian.JIRA>
References: <JIRA.13029803.1482336131000@Atlassian.JIRA> <JIRA.13029803.1482336131808@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13069) Local batchlog for MV may not
 be correctly written on node movements
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 08 Feb 2017 12:10:54 -0000


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

Sylvain Lebresne commented on CASSANDRA-13069:
----------------------------------------------

The patch looks good (though please add braces after the {{if ((pairedEndpoint.get().equals(...))}}) in that it fixes the issue mentioned in the description, and I agree not decrementing the cleanup on local mutations was wrong. But I'm honestly a bit confused about our use of the (local) batchlog for MVs and I don't think it's right.

As far as I can tell, the goal of using a local batchlog is to guarantee eventual consistency of a the base table and its views. That is, no matter what happens for a given update, either both that update and all the related view updates get eventually applied, or none of it is. But unless I'm missing something subtle (for which there is no comment in the code), the batchlog will only guarantees that if _all_ mutations are grouped in it. So I don't understand why:
# we don't include local view mutations in the batchlog in {{SP.mutateMV}}.
# the base table mutation isn't included in said batchlog alongside it's related view updates.

I'll note that fixing the first point in {{mutateMV}} would actually simplify the method and If I'm not completely wrong here I suggest we at least do that on this ticket. It still won't solve the 2nd point, but that's arguably more involved so I'm ok creating a follow-up ticket for that (still, it kind of breaks the one basic guarantee MVs are supposed to provide, so it's kind of critical).


> Local batchlog for MV may not be correctly written on node movements
> --------------------------------------------------------------------
>
>                 Key: CASSANDRA-13069
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13069
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Paulo Motta
>
> Unless I'm really reading this wrong, I think the code [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L829-L843], which comes from CASSANDRA-10674, isn't working properly.
> More precisely, I believe we can have both paired and unpaired mutations, so that both {{if}} can be taken, but if that's the case, the 2nd write to the batchlog will basically overwrite (remove) the batchlog write of the 1st {{if}} and I don't think that's the intention. In practice, this means "paired" mutation won't be in the batchlog, which mean they won't be replayed at all if they fail.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)