I think making it a separate enum config is ok, it is similar to a boolean config but provide more choices, so the config name should be offset.reset.strategy.offset-out-of-range?
- - Best, Ziming > On May 30, 2022, at 9:48 PM, hudeqi <16120...@bjtu.edu.cn> wrote: > > Hi, Ziming. > I thought about it again and thought it might be better to add an additional > auxiliaryStrategy, so that we can implement more auxiliary strategies in this > way, not just nearest. What do you think? > Best, > hudeqi > > > > -----原始邮件----- > > 发件人: hudeqi <16120...@bjtu.edu.cn> > > 发送时间: 2022-05-30 15:33:45 (星期一) > > 收件人: dev@kafka.apache.org > > 抄送: > > 主题: Re: Re: [DISCUSS] KIP-842: Add richer group offset reset mechanisms > > > > 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>
