[
https://issues.apache.org/jira/browse/CASSANDRA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996917#comment-14996917
]
Joel Knighton commented on CASSANDRA-10674:
-------------------------------------------
As I understand it, this doesn't quite support what we were thinking.
Feel free to correct any of this, I'm not particularly well-versed in
streaming. As I understand it, presently, streaming works roughly like:
- Receiving node is receiving a file stream, can fail or retry.
- Receiving node receives file. Receiving node sends received message.
- Receiving node process received file. Receiving node sends a complete message.
In the materialized view path of applying a received file, we'd like to be able
to differentiate between the case of sending a complete message on successful
processing of a received file and sending a retry/error message on failed
processing of a received file (which is not presently possible).
Is there a clean way to do this with current streaming behavior?
> 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
> Fix For: 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)
