Thank you for your reply. According to the current implementation in pull request, it may not be possible to directly remove the enumeration value of nearest. However, on the whole, putting nearest in the OffsetResetStrategy enumeration class may cause some misunderstandings in use. There are two solutions. One is to make a defensive check on the value of "auto.offset.reset" when initializing the consumer, and the other one is that I change the implementation. For example, I add an additional variable named "auxiliaryStrategy" to the SubscriptionState class to reset offset when triggering out-of-range. Besides this problem, is there any other problem? What can I do next to push this kip up for adoption? This is my first time I do, I don't understand very well.
> -----原始邮件----- > 发件人: "deng ziming" <dengziming1...@gmail.com> > 发送时间: 2022-05-30 13:23:53 (星期一) > 收件人: dev@kafka.apache.org > 抄送: > 主题: Re: [DISCUSS] KIP-842: Add richer group offset reset mechanisms > > 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 > >> > > > > ------------------------------ Best, hudeqi </dengziming1...@gmail.com></dengziming1...@gmail.com>
