[
https://issues.apache.org/jira/browse/PHOENIX-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651069#comment-17651069
]
ASF GitHub Bot commented on PHOENIX-5980:
-----------------------------------------
mnpoonia commented on PR #1541:
URL: https://github.com/apache/phoenix/pull/1541#issuecomment-1362372145
@shahrs87 I think now i understand what you are retrying to say. Now that i
look at the metric name again i think we should not consider anything special
about this metric if table is tx or non tx. If we ever need special cases we
can create special metric with some prefix or suffix indicating it is for tx
tables.
Also if we look at the code again ideally a delete statement should not
be part of a batch else(we can talk about it some other day). The problem with
deletes combing with upsert of having multiple delete in same batch is as below
- If we have a batch with two delete statements and if one statement failed
we will get a number saying that x num of deletes failed. But we don't know if
it was first delete stmt or second or both failed. Maybe there is a smart way
to figure out which i will look in code.
> 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)
