frankvicky commented on PR #23687: URL: https://github.com/apache/kafka/pull/23687#issuecomment-6149291898
One thing worth double-checking on the share consumer side. `AsyncKafkaConsumer.pollForFetches()` caps the wait at `retryBackoffMs` while there are no assigned partitions (KAFKA-18376), so a 30s `maximumTimeToWait()` during the first heartbeat is harmless there. https://github.com/apache/kafka/blob/5f684cca20c4a9c096bfa7497a254eed50bc7d5d/clients/src/main/java/org/apache/kafka/clients/consumer/internals/AsyncKafkaConsumer.java#L1994-L1999 `ShareConsumerImpl.pollForFetches()` has no such cap and uses `maximumTimeToWait()` directly. Before this PR the share consumer spun during the first heartbeat, but it surfaced background errors immediately. After this PR, if the first heartbeat fails with a fatal error (e.g. `GROUP_AUTHORIZATION_FAILED`), the application thread stays blocked in `fetchBuffer.awaitNotEmpty()` for `min(request.timeout.ms, poll timeout)` before the error is thrown, since `BackgroundEventHandler` doesn't wake the fetch buffer. Not a blocker, but I'd suggest either adding the same no-assignment cap to `ShareConsumerImpl.pollForFetches()`, or filing a follow-up Jira and linking it here. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
