You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "HaiyuanZhao (Jira)" <ji...@apache.org> on 2020/09/30 15:15:00 UTC
[jira] [Comment Edited] (KAFKA-10504) It will not work to skip to
InitProducerId as lastError is always null
[ https://issues.apache.org/jira/browse/KAFKA-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17204800#comment-17204800 ]
HaiyuanZhao edited comment on KAFKA-10504 at 9/30/20, 3:14 PM:
---------------------------------------------------------------
From my understanding yes.
{code:java}
// @throws TransactionTimedOutException if the producer has encountered a previously aborted transaction on coordinator side.
// Application should catch it and retry starting another transaction in this case.
{code}
As quoted above, when the producer {{encountered an }}{{aborted transaction on coordinator side}}{{. The Application should retry another transaction.}}
However the client side transaction state can't transit from READY to INITIALIZING directly by calling initProducerId. So if client received a TRANSACTIONT_TIME_OUT error, it has to transit to ABORTING_TRANSACTION first by calling abort.
The problem is that the client will also receive TRANSACTIONT_TIME_OUT error by calling abort which enters an endless loop.
My solution refers to the idea of 8805. If the last error is an TRANSACTIONT_TIME_OUT error, Calling abort will skip directly to InitProduceId.
was (Author: zhaohaidao):
From my understanding yes.
```
{{ }}{{* @throws TransactionTimedOutException if the producer has encountered a previously aborted transaction on coordinator side.}}
{{ }}{{* Application should catch it and retry starting another transaction in this case.}}
```
As quoted above, when the producer {{encountered an }}{{aborted transaction on coordinator side}}{{. The Application should retry another transaction.}}
However the client side transaction state can't transit from READY to INITIALIZING directly by calling initProducerId. So if client received a TRANSACTIONT_TIME_OUT error, it has to transit to ABORTING_TRANSACTION first by calling abort.
The problem is that the client will also receive TRANSACTIONT_TIME_OUT error by calling abort which enters an endless loop.
My solution refers to the idea of 8805. If the last error is an TRANSACTIONT_TIME_OUT error, Calling abort will skip directly to InitProduceId.
> It will not work to skip to InitProducerId as lastError is always null
> ----------------------------------------------------------------------
>
> Key: KAFKA-10504
> URL: https://issues.apache.org/jira/browse/KAFKA-10504
> Project: Kafka
> Issue Type: Improvement
> Components: clients
> Reporter: HaiyuanZhao
> Assignee: HaiyuanZhao
> Priority: Major
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> Kafka-8805 introduced an optimization for txn abort process: If the last error is an INVALID_PRODUCER_ID_MAPPING error, skip directly to InitProduceId.
> However this optimization will not work as the var lastError is always null. Because the txn state will transit to ABORTING_TRANSACTION from ABORTABLE_ERROR when beginAbort is called, and the lastError will updated to null.
> So then EndTxn is always called before InitProduceId.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)