[
https://issues.apache.org/jira/browse/KAFKA-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299252#comment-15299252
]
Gwen Shapira commented on KAFKA-3370:
-------------------------------------
Not necessarily efficiency - maybe correctness of some kind.
Right now, we assume that all offsets that are out of range are the same.
It looks like we need finer breakdown:
* First time we see a partition (because we are new, or the partition is new)
* offset too small for range (starting from earliest almost always makes sense?)
* offset too large for range (going to end makes more sense?)
Maybe there are other "special" cases?
> Add options to auto.offset.reset to reset offsets upon initialization only
> --------------------------------------------------------------------------
>
> Key: KAFKA-3370
> URL: https://issues.apache.org/jira/browse/KAFKA-3370
> Project: Kafka
> Issue Type: Bug
> Reporter: Guozhang Wang
> Assignee: Vahid Hashemian
> Fix For: 0.10.1.0
>
>
> Currently "auto.offset.reset" is applied in the following two cases:
> 1) upon starting the consumer for the first time (hence no committed offsets
> before);
> 2) upon fetching offsets out-of-range.
> For scenarios where case 2) needs to be avoid (i.e. people need to be
> notified upon offsets out-of-range rather than silently offset reset),
> "auto.offset.reset" need to be set to "none". However for case 1) setting
> "auto.offset.reset" to "none" will cause NoOffsetForPartitionException upon
> polling. And in this case, seekToBeginning/seekToEnd is mistakenly applied
> trying to set the offset at initialization, which are actually designed for
> during the life time of the consumer (in rebalance callback, for example).
> The fix proposal is to add two more options to "auto.offset.reset",
> "earliest-on-start", and "latest-on-start", whose semantics are "earliest"
> and "latest" for case 1) only, and "none" for case 2).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
