You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Cameron Zemek (Jira)" <ji...@apache.org> on 2021/03/31 01:08:00 UTC
[jira] [Updated] (CASSANDRA-16548) Remove ViewMutationStage as its
unused
[ https://issues.apache.org/jira/browse/CASSANDRA-16548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cameron Zemek updated CASSANDRA-16548:
--------------------------------------
Description:
I been testing and tracing the code and as far as I can determine ViewMutationStage is unused. Looking at StorageProxy::mutateMV if the MV mutation is on same endpoint as the base table endpoint it calls mutation.apply(writeCommitLog); which happens on MutationStage.
If the endpoint is a different endpoint it ends with call to asyncWriteBatchedMutations(wrappers, localDataCenter, Stage.VIEW_MUTATION); which in turn calls sendToHintedReplicas. But this method only uses the passed in stage if executing locally, which in case of the MV mutations is never true in my testing.
So it passes message with MUTATION_REQ which gets handled on the receiving node via MutationStage.
So at no point does the ViewMutationStage get used. I even tried to execute some of the View tests that check for pending tasks on this stage. Well there never even a completed task on that stage so these tests seem to wait on ViewMutationStage for no reason as best I can tell.
Even if the stage is used somewhere, its not used for all view mutations. So this stage is currently in my opinion code bloat and just confusing for the system operator.
An alternative solution to this ticket would be to implement VIEW_MUTATION_REQ etc and have everything MV mutation related run on the ViewMutationStage but that no easy change to make. See CounterMutation for example.
was:
I been testing and tracing the code and as far as I can determine ViewMutationStage is unused. Looking at StorageProxy::mutateMV if the MV mutation is on same endpoint as the base table endpoint it calls mutation.apply(writeCommitLog); which happens on MutationStage.
If the endpoint is a different endpoint it ends with call to asyncWriteBatchedMutations(wrappers, localDataCenter, Stage.VIEW_MUTATION); which calls which in turn calls sendToHintedReplicas. But this method only uses the passed in stage if executing locally, which in case of the MV mutations is never true in my testing.
So it passes message with MUTATION_REQ which gets handled on the receiving node via MutationStage.
So at no point does the ViewMutationStage get used. I even tried to execute some of the View tests that check for pending tasks on this stage. Well there never even a completed task on that stage so these tests seem to wait on ViewMutationStage for no reason as best I can tell.
Even if the stage is used somewhere, its not used for all view mutations. So this stage is currently in my opinion code bloat and just confusing for the system operator.
An alternative solution to this ticket would be to implement VIEW_MUTATION_REQ etc and have everything MV mutation related run on the ViewMutationStage but that no easy change to make. See CounterMutation for example.
> Remove ViewMutationStage as its unused
> --------------------------------------
>
> Key: CASSANDRA-16548
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16548
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Cameron Zemek
> Priority: Normal
>
> I been testing and tracing the code and as far as I can determine ViewMutationStage is unused. Looking at StorageProxy::mutateMV if the MV mutation is on same endpoint as the base table endpoint it calls mutation.apply(writeCommitLog); which happens on MutationStage.
> If the endpoint is a different endpoint it ends with call to asyncWriteBatchedMutations(wrappers, localDataCenter, Stage.VIEW_MUTATION); which in turn calls sendToHintedReplicas. But this method only uses the passed in stage if executing locally, which in case of the MV mutations is never true in my testing.
> So it passes message with MUTATION_REQ which gets handled on the receiving node via MutationStage.
> So at no point does the ViewMutationStage get used. I even tried to execute some of the View tests that check for pending tasks on this stage. Well there never even a completed task on that stage so these tests seem to wait on ViewMutationStage for no reason as best I can tell.
> Even if the stage is used somewhere, its not used for all view mutations. So this stage is currently in my opinion code bloat and just confusing for the system operator.
>
> An alternative solution to this ticket would be to implement VIEW_MUTATION_REQ etc and have everything MV mutation related run on the ViewMutationStage but that no easy change to make. See CounterMutation for example.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org