[
https://issues.apache.org/jira/browse/KAFKA-16474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843324#comment-17843324
]
Lianet Magrans commented on KAFKA-16474:
----------------------------------------
Yes, makes sense, that PR is addressing only point 1. of what you reported, so
we still have the point about the poll frequency (maybe to address separately
if we still believe it's a concern)
> AsyncKafkaConsumer might send out heartbeat request without waiting for its
> response
> ------------------------------------------------------------------------------------
>
> Key: KAFKA-16474
> URL: https://issues.apache.org/jira/browse/KAFKA-16474
> Project: Kafka
> Issue Type: Bug
> Components: clients, consumer
> Reporter: Philip Nee
> Assignee: Philip Nee
> Priority: Critical
> Labels: kip-848-client-support
> Fix For: 3.8.0
>
> Attachments: failing_results.zip
>
>
> KAFKA-16389
> We've discovered that in some uncommon cases, the consumer could send out
> successive heartbeats without waiting for the response to come back. this
> might result in causing the consumer to revoke its just assigned assignments
> in some cases. For example:
>
> The consumer first sends out a heartbeat with epoch=0 and memberId=''
> The consumer then rapidly sends out another heartbeat with epoch=0 and
> memberId='' because it has not gotten any response and thus not updating its
> local state
>
> The consumer receives assignments from the first heartbeat and reconciles its
> assignment.
>
> Since the second heartbeat has epoch=0 and memberId='', the server will think
> this is a new member joining and therefore send out an empty assignment.
>
> The consumer receives the response from the second heartbeat. Revoke all of
> its partitions.
>
> There are 2 issues associate with this bug:
> # inflight logic
> # rapid poll: In the KAFKA-16389 we've observe consumer polling interval to
> be a few ms.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
