adamkotwasinski opened a new pull request, #12364:
URL: https://github.com/apache/kafka/pull/12364
… methods
Having "async" in Kafka consumer API might encourage users to expect that
there is some other internal thread that might deliver offset-commit
confirmation, but actually it's usercode that needs to poll() to get the
response. This PR attempts to add some disclaimer to cover this situation.
In example, the following blocks infinitely:
```
final Consumer<byte[], byte[]> kc = ....
kc.assign(Collections.singleton(new TopicPartition("mytopic", 0)));
kc.poll(2000);
final CountDownLatch latch = new CountDownLatch(1); // The latch
should be released when we get a response.
kc.commitAsync(new OffsetCommitCallback() {
@Override
public void onComplete(final Map<TopicPartition,
OffsetAndMetadata> offsets, final Exception exception) {
latch.countDown();
}
});
latch.await(); // <- Never releases; adding something trivial like
`kc.poll(300)` does help.
```
Obviously the "fix" would be
In detail:
`KafkaConsumer.commitAsync` calls only send the OFFSET_COMMIT requests, but
do not wait for response (as they should be, as they are asynchronous after
all) (the "in-flight" request is kept in NetworkClient's `inFlightRequests`
collection).
However, compared to Producer's asynchronous send API, there is no
underlying worker thread that is going to get the data and invoke the callback
- it is going to happen on the next NetworkClient interaction with remote
(AFAICT anything that should finally invoke `NetworkClient.poll`).
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
--
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
