[
https://issues.apache.org/jira/browse/KAFKA-20115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18056275#comment-18056275
]
David Jacot commented on KAFKA-20115:
-------------------------------------
Hmm… Should the client retry after the request timeout is reached? When it
retries, it will hit the NOT_COORDINATOR (assuming the context is removed), and
it will lookup the new coordinator. I guess that the issue is that the
rebalance is blocked until the client times out and retries. Is my
understanding correct?
> Group coordinator fails to unload metadata when no longer leader or follower
> ----------------------------------------------------------------------------
>
> Key: KAFKA-20115
> URL: https://issues.apache.org/jira/browse/KAFKA-20115
> Project: Kafka
> Issue Type: Bug
> Components: group-coordinator
> Affects Versions: 4.0.1, 4.1.0, 4.2.0, 4.1.1
> Reporter: Sean Quah
> Assignee: Kuan Po Tseng
> Priority: Blocker
>
> KAFKA-19427 introduced logic in the coordinator runtime's
> {{freeCurrentBatch}} to only recycle batch buffers when their size is less
> than or equal to the partition's max message size.
>
> KAFKA-19519 replaced the max message size with the
> group.coordinator.cached.buffer.max.bytes and
> share.coordinator.cached.buffer.max.bytes configs.
> {{PartitionWriter.config()}} throws a {{NOT_LEADER_OR_FOLLOWER}} exception
> when the broker is no longer a leader or follower of the partition.
> When unloading partitions from the group coordinator, we try to free the
> current batch. If the broker is no longer a leader or follower of the
> {{__consumer_offsets}} partition, a {{NOT_LEADER_OR_FOLLOWER}} exception is
> thrown and we do not complete the unload process. This leaves classic group
> rebalance requests like JOIN_GROUP and SYNC_GROUP hanging.
> The bug affects versions after KAFKA-19427 and before KAFKA-19519.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
