Thank you for your reply. According to your description, strategy=nearest is redundant, right? We only rely on nearest.offset.reset=true/false to handle OffsetOutOfRange, I think we can directly remove this enum value, WDYT?
-- Best, Ziming > On May 27, 2022, at 5:19 PM, hudeqi <16120...@bjtu.edu.cn> wrote: > > Thank you for your attention and reply. Here are my reply to your questions: > > 1. If strategy=safe_latest and there is not committed offset, whether the > group is newly started is determined in this way: when the group is started, > a timestamp "createTimeStamp" will be passed as the start time of the group. > When the offset needs to be reset, the timestamp will be added to > "ListOffsetsRequest" as a new field. The server compares the timestamp > "createTimeStamp" with the timestamp "logStartTime", which is the first > message time for each partition. If "createTimeStamp" "greater than > "logStartTime" means that the group is newly started for this partition and > consumed from the latest, otherwise it means that the partition is newly > expanded and needs to be consumed from the earliest. For details, you can see > related jira and pr. > > > > 2. Strictly speaking, nearest is not a level strategy with > earlyliest/latest/safe_latest/earliest_on_start/latest_on_start. It is more > like an auxiliary strategy, which is only dealt with out-of-range. So if you > set nearest.offset.reset=true, no matter what strategy "auto.offset.reset" is > set to, it will be performed according to the strategy of nearest when > out-of-range (to the earliest if it was under the range , or to the latest if > it was over the range), and for the case where no committed offset, nearest > will naturally have no effect, instead, it is determined by the main > strategy(auto.offset.reset). > > > > > 3. This I have added to the form of module "Proposed Changes" in kip-842. > > > > > 4. The meaning of nearest.offset.reset has been clearly expressed in point 2, > this configuration is disabled default, that is to say, when out-of-range, > reset strategy is performed according to the main strategy > (auto.offset.reset). > > > >> -----原始邮件----- >> 发件人: "deng ziming" <dengziming1...@gmail.com> >> 发送时间: 2022-05-27 16:02:53 (星期五) >> 收件人: dev@kafka.apache.org >> 抄送: >> 主题: Re: [DISCUSS] KIP-842: Add richer group offset reset mechanisms >> >> Thank you for this KIP, the motivation makes sense to me, left some >> questions: >> >> 1. If strategy=safe_latest and there is not committed offset, we have 2 >> choices based on whether the group is started newly, can you elaborate on >> how can we decide the group is started newly? It would be clear. >> >> 2. If strategy=nearest and there is not committed offset, its behavior is >> determined by the earliest, or latest, or safe_latest used together. can you >> elaborate on it more clearly? >> >> 3. Can you also add a column "current reset behavior” and change "reset >> behavior” to “proposed reset behavior”, then we can be clear that this has >> no effect on current behavior. >> >> 4. You added a new config “nearest.offset.reset” and only explain what will >> happen when we set it true, you’d better explain what will happen it it is >> false >> >> -- >> Best, >> Ziming >> >> >>> On May 26, 2022, at 10:54 AM, 胡德祺 <16120...@bjtu.edu.cn> wrote: >>> >>> Hi all, >>> Why is no one talking about this? >>> best >>> hudeqi >>> >>> 2022-05-23 17:45:53"胡德祺" <16120...@bjtu.edu.cn>写道： >>> >>> Hi all, >>> >>> I have written a new KIPto add some group offset reset mechanisms. Please >>> take a look here: https://cwiki.apache.org/confluence/x/xhyhD >>> >>> besthudeqi >> > >
