[
https://issues.apache.org/jira/browse/KAFKA-21422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justine Olshan resolved KAFKA-21422.
------------------------------------
Resolution: Fixed
> One failing entry in a WriteTxnMarkers response shouldn't block the rest
> ------------------------------------------------------------------------
>
> Key: KAFKA-21422
> URL: https://issues.apache.org/jira/browse/KAFKA-21422
> Project: Kafka
> Issue Type: Bug
> Reporter: Dongnuo Lyu
> Assignee: Dongnuo Lyu
> Priority: Major
>
> In
> [onComplete|https://github.com/apache/kafka/blob/6c3a5952a1a0a13d828a4d7ba6692a9b3da368e8/core/src/main/scala/kafka/coordinator/transaction/TransactionMarkerRequestCompletionHandler.scala#L94],
> we have no per entry error handling, so the exception leaves the loop and
> every later entry in the same response is skipped. Those transactions have
> their markers written but never acknowledged, and stay in PrepareCommit until
> the __transaction_state partition is reloaded.
>
> The issue was found during a leadership move sending 6 partitions from broker
> 2 and 1 partition from broker 1 to broker 0 while markers are in flight. The
> old leaders reply NOT_LEADER_OR_FOLLOWER. Each response handler re-queues its
> own failed partitions, so broker 0's queue gets two TxnMarkerEntry for the
> same producer.
> Broker 0 merges results per producer id, so the response has one error map
> covering all 7 partitions.
> The handler looks up errors by producer id and iterates the whole map per
> entry, so the 7 partitions are processed twice. The first pass completes the
> transaction. The second pass hits unexpected state.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
