lianetm commented on code in PR #16982:
URL: https://github.com/apache/kafka/pull/16982#discussion_r1754814823
##########
clients/src/test/java/org/apache/kafka/clients/consumer/KafkaConsumerTest.java:
##########
@@ -2479,23 +2487,29 @@ public void testCurrentLag(GroupProtocol groupProtocol)
{
consumer.seek(tp0, 50L);
consumer.poll(Duration.ofMillis(0));
// requests: list-offset, fetch
- assertEquals(2, client.inFlightRequestCount());
Review Comment:
Well definitely this bit is somewhere where the 2 consumers internasl are
different, even though I see them conceptually aligned:
- what's the same in both consumers: a call to consumer lag will "signal"
that it needs to retrieve the log endOffsets
- what's internally done different in both consumers: classic will only
generate the request on the next poll (on the single thread it had and didn't
want to block waiting for the offsets) vs async consumer, where the background
thread poll will pick up the intention already expressed in the app thread and
generate the request to get end offsets.
So I would say we keep the assertion (for the classic as you suggested), and
it will be helpful to show this difference in the test actually. I would add an
explanation for it too: Classic consumer does not send the LIST_OFFSETS right
away (requires an explicit poll), different from the new async consumer, that
will send the LIST_OFFSETS request in the background thread on the next
background thread poll. Makes sense?
With all these tests we're enabling, worth running them repeatedly locally
to try to spot any other flakiness similar to the ones we've been catching.
--
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]
