[
https://issues.apache.org/jira/browse/CASSANDRA-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162434#comment-16162434
]
Paulo Motta commented on CASSANDRA-13069:
-----------------------------------------
Thanks for the review!
bq. 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.
+1
bq. 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.
Agreed, I was not very happy with this either, thanks for noting. The main
reason was to ensure the view batchlog would be replayed on startup, to be able
to test that properly, but I was able to achieve the same effect by [exposing
the batchlog
timeout|https://github.com/apache/cassandra/commit/a3672d5bb825a53c732e9534073c4e1ea729dedd]
via a {{-Dcassandra.batchlog.replay_timeout_in_ms}} property, which [is set
during
dtest|https://github.com/apache/cassandra-dtest/compare/master...pauloricardomg:13069#diff-62ba429edee6a4681782f078246c9893R1943]
and waited before replay.
In practice, this means the user will still need to wait
{{cassandra.batchlog.replay_timeout_in_ms=2*write_request_timeout_in_ms}} to
ensure its failed views will be properly applied after a node is restartated,
but since this is 4s by default it should be acceptable.
Resubmitted CI with the above change. Please let me know what do you think.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
