frankvicky commented on code in PR #19914:
URL: https://github.com/apache/kafka/pull/19914#discussion_r2205033179
##########
clients/clients-integration-tests/src/test/java/org/apache/kafka/clients/consumer/PlaintextConsumerCommitTest.java:
##########
@@ -452,6 +452,36 @@ private void testPositionAndCommit(GroupProtocol
groupProtocol) throws Interrupt
}
}
+ /**
+ * This is testing when closing the consumer but commit request has
already been sent.
+ * During the closing, the consumer won't find the coordinator anymore.
+ */
+ @ClusterTest
+ public void testCommitAsyncFailsWhenCoordinatorUnavailableDuringClose()
throws InterruptedException {
+ try (Producer<byte[], byte[]> producer =
cluster.producer(Map.of(ProducerConfig.ACKS_CONFIG, "all"));
+ var consumer = createConsumer(GroupProtocol.CONSUMER, false)
+ ) {
+ sendRecords(producer, tp, 3, System.currentTimeMillis());
+ consumer.assign(List.of(tp));
+
+ // Try without looking up the coordinator first
+ var callback = new CountConsumerCommitCallback();
+
+ // Close the coordinator before committing because otherwise the
commit will fail to find the coordinator.
+ cluster.brokerIds().forEach(cluster::shutdownBroker);
+
+ consumer.commitAsync(Map.of(tp, new OffsetAndMetadata(1L)),
callback);
+ consumer.commitAsync(Map.of(tp1, new OffsetAndMetadata(1L)),
callback);
Review Comment:
The idea is that when you assign the topicPartition to the consumer, the
coordinator will also be assigned.
To achieve the test scenario, we will need to `poll` again to update
metadata after the brokers shutdown.
After that, the coordinator would be `Optional.empty`, then we could verify
our test case -
To determine if the consumer can fast fail when committing during close.
--
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
