guozhangwang commented on a change in pull request #11631:
URL: https://github.com/apache/kafka/pull/11631#discussion_r778549345
##########
File path:
clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerCoordinator.java
##########
@@ -517,15 +517,13 @@ public boolean poll(Timer timer, boolean
waitForJoinGroup) {
}
}
} else {
- // For manually assigned partitions, if there are no ready nodes,
await metadata.
+ // For manually assigned partitions, if coordinator is unknown,
make sure we lookup one and await metadata.
// If connections to all nodes fail, wakeups triggered while
attempting to send fetch
// requests result in polls returning immediately, causing a tight
loop of polls. Without
// the wakeup, poll() with no channels would block for the
timeout, delaying re-connection.
- // awaitMetadataUpdate() initiates new connections with configured
backoff and avoids the busy loop.
- // When group management is used, metadata wait is already
performed for this scenario as
- // coordinator is unknown, hence this check is not required.
- if (metadata.updateRequested() &&
!client.hasReadyNodes(timer.currentTimeMs())) {
- client.awaitMetadataUpdate(timer);
+ // awaitMetadataUpdate() in ensureCoordinatorReady initiates new
connections with configured backoff and avoids the busy loop.
+ if (coordinatorUnknown() && !ensureCoordinatorReady(timer)) {
+ return false;
Review comment:
I'm wondering if this fix is a bit overkill, e.g. for those consumers
who do not even set the group ID and do not rely on the coordinator for
anything, the `coordinatorUnknown()` would always return true while
`ensureCoordinatorReady` would send a discover coordinator request with `null`
group id.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
