[ https://issues.apache.org/jira/browse/KAFKA-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17819009#comment-17819009 ]
Phuc Hong Tran edited comment on KAFKA-16160 at 2/20/24 11:15 PM: ------------------------------------------------------------------ Also after some findings, I’m thinking that this one is not triggered when the consumer is trying to connect to a disconnected nodes, as the check for disconnected node is right before the check which would produce these logs (See https://github.com/apache/kafka/blob/4c70581eb63fe74494fbabf5a90e87c38e17996d/clients/src/main/java/org/apache/kafka/clients/consumer/internals/NetworkClientDelegate.java#L160) was (Author: JIRAUSER301295): Also after some findings, I’m thinking that this one is not triggered when the consumer is trying to connect to a disconnected nodes, as the check for disconnected node is right before the check which would produce these logs > AsyncKafkaConsumer is trying to connect to a disconnected node in a tight loop > ------------------------------------------------------------------------------ > > Key: KAFKA-16160 > URL: https://issues.apache.org/jira/browse/KAFKA-16160 > Project: Kafka > Issue Type: Bug > Components: clients, consumer > Reporter: Philip Nee > Assignee: Phuc Hong Tran > Priority: Major > Labels: consumer-threading-refactor > Fix For: 3.8.0 > > > Observing some excessive logging running AsyncKafkaConsumer and observing > excessive logging of : > {code:java} > 1271 [2024-01-15 09:43:36,627] DEBUG [Consumer clientId=console-consumer, > groupId=concurrent_consumer] Node is not ready, handle the request in the > next event loop: node=worker4:9092 (id: 2147483644 rack: null), > request=UnsentRequest{requestBuil > der=ConsumerGroupHeartbeatRequestData(groupId='concurrent_consumer', > memberId='laIqS789StuhXFpTwjh6hA', memberEpoch=1, instanceId=null, > rackId=null, rebalanceTimeoutMs=300000, subscribedTopicNames=[output-topic], > serverAssignor=null, topicP > artitions=[TopicPartitions(topicId=I5P5lIXvR1Cjc8hfoJg5bg, partitions=[0])]), > handler=org.apache.kafka.clients.consumer.internals.NetworkClientDelegate$FutureCompletionHandler@918925b, > node=Optional[worker4:9092 (id: 2147483644 rack: null)] , > timer=org.apache.kafka.common.utils.Timer@55ed4733} > (org.apache.kafka.clients.consumer.internals.NetworkClientDelegate) {code} > This seems to be triggered by a tight poll loop of the network thread. The > right thing to do is to backoff a bit for that given node and retry later. > This should be a blocker for 3.8 release. -- This message was sent by Atlassian Jira (v8.20.10#820010)