[
https://issues.apache.org/jira/browse/PHOENIX-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649367#comment-17649367
]
ASF GitHub Bot commented on PHOENIX-5980:
-----------------------------------------
mnpoonia commented on PR #1541:
URL: https://github.com/apache/phoenix/pull/1541#issuecomment-1357819106
>I think we need to use DELETE_BATCH_FAILED_SIZE, right? That was the reason
this JIRA was created in the first place. Am I understanding something wrong?
Table being transactional doesn't have to do anything with how many deletes
failed in that batch. Both are orthogonal. We tried to delete 4 rows and that
failed. So the metric should reflect how many rows we tried to delete and
failed.
@shahrs87 You are right. table being transactional or not doesn't change the
value of DELETE_BATCH_FAILED_SIZE. But when it comes to mutation while we
are in transactional table we consider a set of command as single mutation
and that can be only reason i consider that MUTATION_BATCH_FAILED_SIZE differs.
So in that sense it looks fine. What do you think we are missing here?
> MUTATION_BATCH_FAILED_SIZE metric is incorrectly updated for failing delete
> mutations
> -------------------------------------------------------------------------------------
>
> Key: PHOENIX-5980
> URL: https://issues.apache.org/jira/browse/PHOENIX-5980
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0
> Reporter: Chinmay Kulkarni
> Assignee: Aman Poonia
> Priority: Major
> Labels: metrics, phoenix-hardening, quality-improvement
> Fix For: 4.17.0, 4.16.2
>
>
> In the conn.commit() path, we get the number of mutations that failed to be
> committed in the catch block of MutationState.sendMutations() (see
> [here|https://github.com/apache/phoenix/blob/dcc88af8acc2ba8df10d2e9d498ab3646fdf0a78/phoenix-core/src/main/java/org/apache/phoenix/execute/MutationState.java#L1195-L1198]).
>
> In case of delete mutations, the uncommittedStatementIndexes.length always
> resolves to 1 and we always update the metric value by 1 in this case, even
> though the actual mutation list corresponds to multiple DELETE mutations
> which failed. In case of upserts, using unCommittedStatementIndexes.length is
> fine since each upsert query corresponds to 1 Put. We should fix the logic
> for deletes/mixed delete + upsert mutation batch failures.
> This wrong value is propagated to global client metrics as well as
> MutationMetricQueue metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
