[
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: [email protected]
For additional commands, e-mail: [email protected]
