Is there any more attention to this KIP?
bump this thread.
Best,
hudeqi
hudeqi 16120...@bjtu.edu.cn写道：
> Hello, have any mates who have discussed it before seen it? Also welcome new
> mates to discuss together.
>
> hudeqi 16120...@bjtu.edu.cn写道：
> > Long time no see, this issue has been
I repost the newly changed KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-842%3A+Add+richer+group+offset+reset+mechanisms
hudeqi 16120...@bjtu.edu.cn写道：
> Hello, have any mates who have discussed it before seen it? Also welcome new
> mates to discuss together.
>
> hudeqi
Hello, have any mates who have discussed it before seen it? Also welcome new
mates to discuss together.
hudeqi 16120...@bjtu.edu.cn写道：
> Long time no see, this issue has been discussed for a long time, now please
> allow me to summarize this issue, and then everyone can help to see which
>
- clicked "send" by mistake... here's the full email -
Hello Deqi,
Thanks for bringing this KIP, and sorry for getting back to you so late.
I do think that separating the reset policy for the two scenarios: 1) when
we get an out-of-range when polling records, likely due to log being
Hello Deqi,
Thanks for bringing this KIP, and sorry for getting back to you so late.
I do think that separating the reset policy for the two scenarios: 1) when
we get an out-of-range when polling records, likely due to log being
truncated, 2) when we start fetching and there's no committed
Regarding the option to integrate repair logic in "latest", I understand your
concern about this approach: backward compatibility.
But we should have a consensus: the problem of data loss due to expand
partitions is indeed caused by kafka's own design mechanism. The user
configuration "latest"
Thanks for your attention and reply.
Having chatted with Guozhang Wang at KAFKA-12478 before, I came up with an idea
similar to yours. It's just not implemented on the client side, but on the
server side: Firstly, find out all the groups subscribed to this topic before
extending partitions, and
Thanks for your attention and reply.
Regarding the problem raised by this kip, if you have other ideas or solutions,
you are welcome to put forward them, thank you.
Best,
hudeqi
David Jacot da...@apache.org写道：
> Thanks for the KIP.
>
> I read it and I am also worried by the complexity of the
Thanks for your attention and reply.
If it is put together with "latest", the "safe_latest" does look a bit strange,
which may make users not know which one to choose. In essence, "safe_latest" is
to solve the situation that data may be lost after extending partition, so I
think it is better to
I think so too, what about Guozhang Wang and Luke Chen? Can I initiate a voting
process?
Best,
hudeqi
-原始邮件-
发件人: "邓子明"
发送时间: 2022-06-07 10:23:37 (星期二)
收件人: dev@kafka.apache.org
抄送:
主题: Re: [DISCUSS] KIP-842: Add richer group offset reset mechanisms
: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
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
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
13 matches
Mail list logo
