lianetm commented on code in PR #23014:
URL: https://github.com/apache/kafka/pull/23014#discussion_r3759394400
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/AbstractFetch.java:
##########
@@ -484,7 +488,48 @@ protected Map<Node, FetchSessionHandler.FetchRequestData>
prepareFetchRequests()
}
}
- return convert(fetchable);
+ // If every fetchable-but-unbuffered partition was skipped (for
example, due to reconnect backoff,
Review Comment:
uhm interesting, in this case, do we leave the app thread to block, but how
does that get bounded? I don't see the fetchReqMgr overrides the
`maximumTimeToWait` (should we?), so I guess whatever other managers bring will
win? (e.g, hb interval if in a group).
https://github.com/apache/kafka/blob/e2aa6d676f260d147302179a7a9cf3af369f01ad/clients/src/main/java/org/apache/kafka/clients/consumer/internals/AsyncKafkaConsumer.java#L1986-L1988
Getting that time boundary right is key here imo, we're moving from waking
up too much to just waking up in specific cases (challenge is to make sure we
don't leave the app thread blocking needlessly then, would probably turn into
fetch latency not generating next requests soon enough)
--
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]
