[
https://issues.apache.org/jira/browse/CASSANDRA-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152068#comment-16152068
]
Kurt Greaves commented on CASSANDRA-12783:
------------------------------------------
Thanks for pointing that out for the UUIDs. Issue seems fixed now.
Regarding 2 & 3, I see that [~carlyeks] implemented
[{{separateUpdates}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/view/TableViews.java#L265]
in the view write path to ensure normal updates only generate a single
mutation to avoid the case of splitting a MV update over multiple batches (I
think?). With the whole "active" batch method could we remove the
{{separateUpdates}} case and instead split it over multiple batches, however
only set them to be active once they are all written, and fail the write if any
batch {{store}} errors?
Not super familiar with that code so not really sure if it covers all the
potential MV cases, but if it'd work I think it would be much cleaner than
breaking apart batches during store.
> Break up large MV mutations to prevent OOMs
> -------------------------------------------
>
> Key: CASSANDRA-12783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12783
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths, Materialized Views
> Reporter: Carl Yeksigian
> Assignee: Kurt Greaves
> Fix For: 4.x
>
>
> We only use the code path added in CASSANDRA-12268 for the view builder
> because otherwise we would break the contract of the batchlog, where some
> mutations may be written and pushed out before the whole batch log has been
> saved.
> We would need to ensure that all of the updates make it to the batchlog
> before allowing the batchlog manager to try to replay them, but also before
> we start pushing out updates to the paired replicas.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
