[
https://issues.apache.org/jira/browse/CASSANDRA-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161002#comment-16161002
]
Sylvain Lebresne commented on CASSANDRA-13069:
----------------------------------------------
What I had in mind was more about simplifying the whole view write patch to be
1) write a batchlog for local+view mutations and then 2) apply those mutations,
which implied rewriting {{Keyspace.apply}} so we don't start by writing the
base mutation in the commit log for instance, and I still think it would be
both simpler code-wise and be more easy to reason about correction. But this is
admittedly not the place to debate about this, and you are right that things
aren't as grim as I portrayed it in my previous comment anyway, so happy to
focus on just the bug for which this was opened for.
So things mostly look good except for the {{isFirstReplay}} addition in
{{BatchLogManager}} that I'm fairly unsure about. My understanding is that the
main goal of the batchlog delay is to avoid replaying batches that may still
have a change to succeed, but your change seems to break that, so it sounds
like that could have adverse performance effect, including on non-view usages
of the batchlog. To be honest though, the batchlog code isn't my main area of
expertise, so if if you feel this is important and not a real problem, I'd
prefer we isolate that change to a separate ticket so it is looked in its own
right (and preferably by someone more knowledgeable of that code).
> 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
> Components: Materialized Views
> 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
