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

Paulo Motta commented on CASSANDRA-10674:
-----------------------------------------

bq. In the new {{mutateMV}}, pairedEndpoint.isPresent() in the conditional 
takes care of the first place but not the second while there are 
pendingEndpoints.

That's right, good catch! I simplified but only thinking of the first case, but 
indeed the second scenario is valid as there may be a pending joining node 
which will be a natural endpoint for that view update. Update this and minor 
typo and re-submitted tests.

Something I don't get in the fist scenario though is that besides writing to 
the batchlog, the node is also persisting the mutation locally via the 
{{asyncWriteBatchedMutations}} call, so the batchlog is cleaned if this call is 
successful afaik. If there are no natural view endpoints, shouldn't we write 
only to the batchlog and skip the local write via 
{{asyncWriteBatchedMutations}}?

> Materialized View SSTable streaming/leaving status race on decommission
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-10674
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10674
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination, Distributed Metadata
>            Reporter: Joel Knighton
>            Assignee: Paulo Motta
>             Fix For: 3.0.1, 3.1
>
>         Attachments: leaving-node-debug.log, receiving-node-debug.log
>
>
> On decommission of a node in a cluster with materialized views, it is 
> possible for the decommissioning node to begin streaming sstables for an MV 
> base table before the receiving node is aware of the leaving status.
> The materialized view base/view replica pairing checks pending endpoints to 
> handle the case when an sstable is received from a leaving node; without the 
> leaving message, this check breaks and an exception is thrown. The streamed 
> sstable is never applied.
> Logs from a decommissioning node and a node receiving such a stream are 
> attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to