showuon commented on code in PR #12753:
URL: https://github.com/apache/kafka/pull/12753#discussion_r1029965479
##########
clients/src/main/java/org/apache/kafka/clients/consumer/KafkaConsumer.java:
##########
@@ -1581,6 +1581,26 @@ public void commitAsync(final Map<TopicPartition,
OffsetAndMetadata> offsets, Of
* is invoked for the same partition more than once, the latest offset
will be used on the next poll(). Note that
* you may lose data if this API is arbitrarily used in the middle of
consumption, to reset the fetch offsets
*
+ * The next Consumer Record which will be retrieved when poll() is invoked
will have the offset specified, given that
+ * a record with that offset exists (ie: it is a valid offset).
+ *
+ * seek(0) is equivalent to seek to beginning for a topic with beginning
offset 0,
+ * assuming that there is a record at offset 0 still available.
+ * seekToEnd() is equivalent to seeking to the highest known offset + 1.
+ *
+ * Seeking to the offset smaller than the log start offset or larger than
the log end offset
+ * or high watermark means an invalid offset is reached.
+ * Invalid offset behaviour is controlled by
+ * the {@link ConsumerConfig AUTO_RESET_CONFIG} property.
+ * If this is set to "earliest", the next poll will return records from
the starting offset.
+ * If it is set to "latest", it will seek to the last known record
(similar to seekToEnd()).
+ * If it is set to "none", an {@link OffsetOutOfRangeException} will be
thrown.
+ *
+ * Note that, the seek offset won't change to the in-flight fetch
request, it will take effect in next fetch request.
+ * In order for the invalid offset behaviour to take effect immediately
after seeking and polling,
+ * {@link ConsumerConfig FETCH_MAX_WAIT_MS_CONFIG} should be set to 0.
Review Comment:
1. Please change `{@link ConsumerConfig FETCH_MAX_WAIT_MS_CONFIG}` to
`{@code fetch.max.wait.ms}`
2. I don't think we should recommend users set fetch.max.wait.ms=0 here. We
just need to explain why it won't take effect immediately.
Maybe:
`Note that, the seek offset won't change to the in-flight fetch request, it
will take effect in next fetch request. So, it might wait for {@code
fetch.max.wait.ms} before starting fetching the records from desired offset.`
WDYT?
--
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
