You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Colin McCabe <cm...@apache.org> on 2017/10/17 18:11:58 UTC
[VOTE] KIP-207:The Offsets which ListOffsetsResponse returns should
monotonically increase even during a partition leader change
Hi all,
I'd like to start the voting process for KIP-207:The Offsets which
ListOffsetsResponse returns should monotonically increase even during a
partition leader change.
See
https://cwiki.apache.org/confluence/display/KAFKA/KIP-207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+monotonically+increasing+even+during+a+partition+leader+change
for details.
The voting process will run for at least 72 hours.
regards,
Colin
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Ted Yu <yu...@gmail.com>.
+1
On Tue, Oct 17, 2017 at 11:23 AM, Apurva Mehta <ap...@confluent.io> wrote:
> +1 (non-binding)
>
> On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org> wrote:
>
> > Hi all,
> >
> > I'd like to start the voting process for KIP-207:The Offsets which
> > ListOffsetsResponse returns should monotonically increase even during a
> > partition leader change.
> >
> > See
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > monotonically+increasing+even+during+a+partition+leader+change
> > for details.
> >
> > The voting process will run for at least 72 hours.
> >
> > regards,
> > Colin
> >
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Apurva Mehta <ap...@confluent.io>.
+1 (non-binding)
On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org> wrote:
> Hi all,
>
> I'd like to start the voting process for KIP-207:The Offsets which
> ListOffsetsResponse returns should monotonically increase even during a
> partition leader change.
>
> See
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> monotonically+increasing+even+during+a+partition+leader+change
> for details.
>
> The voting process will run for at least 72 hours.
>
> regards,
> Colin
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Satish Duggana <sa...@gmail.com>.
+1 (non binding)
Thanks,
Satish.
On Wed, Oct 18, 2017 at 1:56 AM, Jun Rao <ju...@confluent.io> wrote:
> Hi, Colin,
>
> Thanks for the KIP. +1. Just a minor comment. For the old client requests,
> would it be better to return a LEADER_NOT_AVAILABLE error instead?
>
> Jun
>
> On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org> wrote:
>
> > Hi all,
> >
> > I'd like to start the voting process for KIP-207:The Offsets which
> > ListOffsetsResponse returns should monotonically increase even during a
> > partition leader change.
> >
> > See
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > monotonically+increasing+even+during+a+partition+leader+change
> > for details.
> >
> > The voting process will run for at least 72 hours.
> >
> > regards,
> > Colin
> >
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns should
monotonically increase even during a partition leader change
Posted by Colin McCabe <cm...@apache.org>.
On Tue, Oct 17, 2017, at 13:26, Jun Rao wrote:
> Hi, Colin,
>
> Thanks for the KIP. +1. Just a minor comment. For the old client
> requests,
> would it be better to return a LEADER_NOT_AVAILABLE error instead?
Good idea. I changed it to LeaderNotAvailableException.
best,
Colin
>
> Jun
>
> On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org>
> wrote:
>
> > Hi all,
> >
> > I'd like to start the voting process for KIP-207:The Offsets which
> > ListOffsetsResponse returns should monotonically increase even during a
> > partition leader change.
> >
> > See
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > monotonically+increasing+even+during+a+partition+leader+change
> > for details.
> >
> > The voting process will run for at least 72 hours.
> >
> > regards,
> > Colin
> >
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns should
monotonically increase even during a partition leader change
Posted by Colin McCabe <cm...@apache.org>.
Hi all,
With binding +1 votes from Jason Gustafson, Jun Rao, and Ismael Juma,
non-binding +1 votes from Manikumar, and no +0 or -1 votes, the vote
passes.
best,
Colin
On Fri, Oct 27, 2017, at 11:09, Colin McCabe wrote:
> Thanks, everyone. I'm going to close the vote tomorrow if there are no
> more comments or votes.
>
> regards,
> Colin
>
>
> On Thu, Oct 26, 2017, at 08:09, Manikumar wrote:
> > Thanks for the KIP.
> > +1 (non-binding)
> >
> >
> > On Thu, Oct 26, 2017 at 5:58 AM, Jason Gustafson <ja...@confluent.io>
> > wrote:
> >
> > > +1. Thanks for the KIP.
> > >
> > > On Mon, Oct 23, 2017 at 11:30 AM, Colin McCabe <cm...@apache.org> wrote:
> > >
> > > > On Mon, Oct 23, 2017, at 10:29, Jason Gustafson wrote:
> > > > > Thanks for the KIP. I'm assuming the new behavior only affects
> > > > > ListOffsets requests from the consumer.
> > > >
> > > > That's a very good point. I will add a caveat that we only apply the
> > > > KIP-207 behavior to requests from clients, not requests from other
> > > > brokers (such as the ones made by ReplicaFetcherThread).
> > > >
> > > > > Might be worth mentioning that in the KIP.
> > > > > Also, does it affect all ListOffsets requests, or only those that
> > > specify
> > > > > the latest offset?
> > > >
> > > > I don't feel great about allowing someone to ask for the offset at time
> > > > T, get back X, and then ask again for the offset at T the next second
> > > > and get back InvalidOffsetException. So it's probably best just to
> > > > apply the KIP-207 behavior to all ListOffsets requests from consumers.
> > > >
> > > > Thinking about it a bit more, we should disable the KIP-207 behavior
> > > > when unclean leader elections are enabled on the broker. When unclean
> > > > leader elections are enabled, data loss is possible. So we cannot
> > > > guarantee that offsets will always go forwards, even in theory, in this
> > > > mode.
> > > >
> > > > I update the kip-- check it out.
> > > >
> > > > best,
> > > > Colin
> > > >
> > > >
> > > > >
> > > > > -Jason
> > > > >
> > > > > On Wed, Oct 18, 2017 at 9:15 AM, Colin McCabe <cm...@apache.org>
> > > > wrote:
> > > > >
> > > > > > On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> > > > > > > Thanks for the KIP, +1 (binding). A few comments:
> > > > > > >
> > > > > > > 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code
> > > for
> > > > > > > older
> > > > > > > versions.
> > > > > > > 2. OffsetNotAvailableException seems clear enough (i.e. we don't
> > > > need the
> > > > > > > "ForPartition" part)
> > > > > >
> > > > > > Yeah, that is shorter and probably clearer. Changed.
> > > > > >
> > > > > > > 3. The KIP seems to be missing the compatibility section.
> > > > > >
> > > > > > Added.
> > > > > >
> > > > > > > 4. It would be good to mention that it's now possible for a fetch
> > > to
> > > > > > > succeed while list offsets will not for a period of time. And for
> > > > older
> > > > > > > versions, the latter will return LeaderNotAvailable while the
> > > former
> > > > > > > would
> > > > > > > work fine, which is a bit unexpected. Not much we can do about it,
> > > > but
> > > > > > > worth mentioning it in my opinion.
> > > > > >
> > > > > > Fair enough
> > > > > >
> > > > > > cheers,
> > > > > > Colin
> > > > > >
> > > > > > >
> > > > > > > Ismael
> > > > > > >
> > > > > > > On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> > > > > > >
> > > > > > > > Hi, Colin,
> > > > > > > >
> > > > > > > > Thanks for the KIP. +1. Just a minor comment. For the old client
> > > > > > requests,
> > > > > > > > would it be better to return a LEADER_NOT_AVAILABLE error
> > > instead?
> > > > > > > >
> > > > > > > > Jun
> > > > > > > >
> > > > > > > > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <
> > > cmccabe@apache.org
> > > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > I'd like to start the voting process for KIP-207:The Offsets
> > > > which
> > > > > > > > > ListOffsetsResponse returns should monotonically increase even
> > > > > > during a
> > > > > > > > > partition leader change.
> > > > > > > > >
> > > > > > > > > See
> > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > > > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > > > > > > > monotonically+increasing+even+during+a+partition+leader+change
> > > > > > > > > for details.
> > > > > > > > >
> > > > > > > > > The voting process will run for at least 72 hours.
> > > > > > > > >
> > > > > > > > > regards,
> > > > > > > > > Colin
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns should
monotonically increase even during a partition leader change
Posted by Colin McCabe <cm...@apache.org>.
Thanks, everyone. I'm going to close the vote tomorrow if there are no
more comments or votes.
regards,
Colin
On Thu, Oct 26, 2017, at 08:09, Manikumar wrote:
> Thanks for the KIP.
> +1 (non-binding)
>
>
> On Thu, Oct 26, 2017 at 5:58 AM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > +1. Thanks for the KIP.
> >
> > On Mon, Oct 23, 2017 at 11:30 AM, Colin McCabe <cm...@apache.org> wrote:
> >
> > > On Mon, Oct 23, 2017, at 10:29, Jason Gustafson wrote:
> > > > Thanks for the KIP. I'm assuming the new behavior only affects
> > > > ListOffsets requests from the consumer.
> > >
> > > That's a very good point. I will add a caveat that we only apply the
> > > KIP-207 behavior to requests from clients, not requests from other
> > > brokers (such as the ones made by ReplicaFetcherThread).
> > >
> > > > Might be worth mentioning that in the KIP.
> > > > Also, does it affect all ListOffsets requests, or only those that
> > specify
> > > > the latest offset?
> > >
> > > I don't feel great about allowing someone to ask for the offset at time
> > > T, get back X, and then ask again for the offset at T the next second
> > > and get back InvalidOffsetException. So it's probably best just to
> > > apply the KIP-207 behavior to all ListOffsets requests from consumers.
> > >
> > > Thinking about it a bit more, we should disable the KIP-207 behavior
> > > when unclean leader elections are enabled on the broker. When unclean
> > > leader elections are enabled, data loss is possible. So we cannot
> > > guarantee that offsets will always go forwards, even in theory, in this
> > > mode.
> > >
> > > I update the kip-- check it out.
> > >
> > > best,
> > > Colin
> > >
> > >
> > > >
> > > > -Jason
> > > >
> > > > On Wed, Oct 18, 2017 at 9:15 AM, Colin McCabe <cm...@apache.org>
> > > wrote:
> > > >
> > > > > On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> > > > > > Thanks for the KIP, +1 (binding). A few comments:
> > > > > >
> > > > > > 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code
> > for
> > > > > > older
> > > > > > versions.
> > > > > > 2. OffsetNotAvailableException seems clear enough (i.e. we don't
> > > need the
> > > > > > "ForPartition" part)
> > > > >
> > > > > Yeah, that is shorter and probably clearer. Changed.
> > > > >
> > > > > > 3. The KIP seems to be missing the compatibility section.
> > > > >
> > > > > Added.
> > > > >
> > > > > > 4. It would be good to mention that it's now possible for a fetch
> > to
> > > > > > succeed while list offsets will not for a period of time. And for
> > > older
> > > > > > versions, the latter will return LeaderNotAvailable while the
> > former
> > > > > > would
> > > > > > work fine, which is a bit unexpected. Not much we can do about it,
> > > but
> > > > > > worth mentioning it in my opinion.
> > > > >
> > > > > Fair enough
> > > > >
> > > > > cheers,
> > > > > Colin
> > > > >
> > > > > >
> > > > > > Ismael
> > > > > >
> > > > > > On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> > > > > >
> > > > > > > Hi, Colin,
> > > > > > >
> > > > > > > Thanks for the KIP. +1. Just a minor comment. For the old client
> > > > > requests,
> > > > > > > would it be better to return a LEADER_NOT_AVAILABLE error
> > instead?
> > > > > > >
> > > > > > > Jun
> > > > > > >
> > > > > > > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <
> > cmccabe@apache.org
> > > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I'd like to start the voting process for KIP-207:The Offsets
> > > which
> > > > > > > > ListOffsetsResponse returns should monotonically increase even
> > > > > during a
> > > > > > > > partition leader change.
> > > > > > > >
> > > > > > > > See
> > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > > > > > > monotonically+increasing+even+during+a+partition+leader+change
> > > > > > > > for details.
> > > > > > > >
> > > > > > > > The voting process will run for at least 72 hours.
> > > > > > > >
> > > > > > > > regards,
> > > > > > > > Colin
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Manikumar <ma...@gmail.com>.
Thanks for the KIP.
+1 (non-binding)
On Thu, Oct 26, 2017 at 5:58 AM, Jason Gustafson <ja...@confluent.io> wrote:
> +1. Thanks for the KIP.
>
> On Mon, Oct 23, 2017 at 11:30 AM, Colin McCabe <cm...@apache.org> wrote:
>
> > On Mon, Oct 23, 2017, at 10:29, Jason Gustafson wrote:
> > > Thanks for the KIP. I'm assuming the new behavior only affects
> > > ListOffsets requests from the consumer.
> >
> > That's a very good point. I will add a caveat that we only apply the
> > KIP-207 behavior to requests from clients, not requests from other
> > brokers (such as the ones made by ReplicaFetcherThread).
> >
> > > Might be worth mentioning that in the KIP.
> > > Also, does it affect all ListOffsets requests, or only those that
> specify
> > > the latest offset?
> >
> > I don't feel great about allowing someone to ask for the offset at time
> > T, get back X, and then ask again for the offset at T the next second
> > and get back InvalidOffsetException. So it's probably best just to
> > apply the KIP-207 behavior to all ListOffsets requests from consumers.
> >
> > Thinking about it a bit more, we should disable the KIP-207 behavior
> > when unclean leader elections are enabled on the broker. When unclean
> > leader elections are enabled, data loss is possible. So we cannot
> > guarantee that offsets will always go forwards, even in theory, in this
> > mode.
> >
> > I update the kip-- check it out.
> >
> > best,
> > Colin
> >
> >
> > >
> > > -Jason
> > >
> > > On Wed, Oct 18, 2017 at 9:15 AM, Colin McCabe <cm...@apache.org>
> > wrote:
> > >
> > > > On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> > > > > Thanks for the KIP, +1 (binding). A few comments:
> > > > >
> > > > > 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code
> for
> > > > > older
> > > > > versions.
> > > > > 2. OffsetNotAvailableException seems clear enough (i.e. we don't
> > need the
> > > > > "ForPartition" part)
> > > >
> > > > Yeah, that is shorter and probably clearer. Changed.
> > > >
> > > > > 3. The KIP seems to be missing the compatibility section.
> > > >
> > > > Added.
> > > >
> > > > > 4. It would be good to mention that it's now possible for a fetch
> to
> > > > > succeed while list offsets will not for a period of time. And for
> > older
> > > > > versions, the latter will return LeaderNotAvailable while the
> former
> > > > > would
> > > > > work fine, which is a bit unexpected. Not much we can do about it,
> > but
> > > > > worth mentioning it in my opinion.
> > > >
> > > > Fair enough
> > > >
> > > > cheers,
> > > > Colin
> > > >
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> > > > >
> > > > > > Hi, Colin,
> > > > > >
> > > > > > Thanks for the KIP. +1. Just a minor comment. For the old client
> > > > requests,
> > > > > > would it be better to return a LEADER_NOT_AVAILABLE error
> instead?
> > > > > >
> > > > > > Jun
> > > > > >
> > > > > > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <
> cmccabe@apache.org
> > >
> > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I'd like to start the voting process for KIP-207:The Offsets
> > which
> > > > > > > ListOffsetsResponse returns should monotonically increase even
> > > > during a
> > > > > > > partition leader change.
> > > > > > >
> > > > > > > See
> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > > > > > monotonically+increasing+even+during+a+partition+leader+change
> > > > > > > for details.
> > > > > > >
> > > > > > > The voting process will run for at least 72 hours.
> > > > > > >
> > > > > > > regards,
> > > > > > > Colin
> > > > > > >
> > > > > >
> > > >
> >
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Jason Gustafson <ja...@confluent.io>.
+1. Thanks for the KIP.
On Mon, Oct 23, 2017 at 11:30 AM, Colin McCabe <cm...@apache.org> wrote:
> On Mon, Oct 23, 2017, at 10:29, Jason Gustafson wrote:
> > Thanks for the KIP. I'm assuming the new behavior only affects
> > ListOffsets requests from the consumer.
>
> That's a very good point. I will add a caveat that we only apply the
> KIP-207 behavior to requests from clients, not requests from other
> brokers (such as the ones made by ReplicaFetcherThread).
>
> > Might be worth mentioning that in the KIP.
> > Also, does it affect all ListOffsets requests, or only those that specify
> > the latest offset?
>
> I don't feel great about allowing someone to ask for the offset at time
> T, get back X, and then ask again for the offset at T the next second
> and get back InvalidOffsetException. So it's probably best just to
> apply the KIP-207 behavior to all ListOffsets requests from consumers.
>
> Thinking about it a bit more, we should disable the KIP-207 behavior
> when unclean leader elections are enabled on the broker. When unclean
> leader elections are enabled, data loss is possible. So we cannot
> guarantee that offsets will always go forwards, even in theory, in this
> mode.
>
> I update the kip-- check it out.
>
> best,
> Colin
>
>
> >
> > -Jason
> >
> > On Wed, Oct 18, 2017 at 9:15 AM, Colin McCabe <cm...@apache.org>
> wrote:
> >
> > > On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> > > > Thanks for the KIP, +1 (binding). A few comments:
> > > >
> > > > 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code for
> > > > older
> > > > versions.
> > > > 2. OffsetNotAvailableException seems clear enough (i.e. we don't
> need the
> > > > "ForPartition" part)
> > >
> > > Yeah, that is shorter and probably clearer. Changed.
> > >
> > > > 3. The KIP seems to be missing the compatibility section.
> > >
> > > Added.
> > >
> > > > 4. It would be good to mention that it's now possible for a fetch to
> > > > succeed while list offsets will not for a period of time. And for
> older
> > > > versions, the latter will return LeaderNotAvailable while the former
> > > > would
> > > > work fine, which is a bit unexpected. Not much we can do about it,
> but
> > > > worth mentioning it in my opinion.
> > >
> > > Fair enough
> > >
> > > cheers,
> > > Colin
> > >
> > > >
> > > > Ismael
> > > >
> > > > On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> > > >
> > > > > Hi, Colin,
> > > > >
> > > > > Thanks for the KIP. +1. Just a minor comment. For the old client
> > > requests,
> > > > > would it be better to return a LEADER_NOT_AVAILABLE error instead?
> > > > >
> > > > > Jun
> > > > >
> > > > > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cmccabe@apache.org
> >
> > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I'd like to start the voting process for KIP-207:The Offsets
> which
> > > > > > ListOffsetsResponse returns should monotonically increase even
> > > during a
> > > > > > partition leader change.
> > > > > >
> > > > > > See
> > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > > > > monotonically+increasing+even+during+a+partition+leader+change
> > > > > > for details.
> > > > > >
> > > > > > The voting process will run for at least 72 hours.
> > > > > >
> > > > > > regards,
> > > > > > Colin
> > > > > >
> > > > >
> > >
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns should
monotonically increase even during a partition leader change
Posted by Colin McCabe <cm...@apache.org>.
On Mon, Oct 23, 2017, at 10:29, Jason Gustafson wrote:
> Thanks for the KIP. I'm assuming the new behavior only affects
> ListOffsets requests from the consumer.
That's a very good point. I will add a caveat that we only apply the
KIP-207 behavior to requests from clients, not requests from other
brokers (such as the ones made by ReplicaFetcherThread).
> Might be worth mentioning that in the KIP.
> Also, does it affect all ListOffsets requests, or only those that specify
> the latest offset?
I don't feel great about allowing someone to ask for the offset at time
T, get back X, and then ask again for the offset at T the next second
and get back InvalidOffsetException. So it's probably best just to
apply the KIP-207 behavior to all ListOffsets requests from consumers.
Thinking about it a bit more, we should disable the KIP-207 behavior
when unclean leader elections are enabled on the broker. When unclean
leader elections are enabled, data loss is possible. So we cannot
guarantee that offsets will always go forwards, even in theory, in this
mode.
I update the kip-- check it out.
best,
Colin
>
> -Jason
>
> On Wed, Oct 18, 2017 at 9:15 AM, Colin McCabe <cm...@apache.org> wrote:
>
> > On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> > > Thanks for the KIP, +1 (binding). A few comments:
> > >
> > > 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code for
> > > older
> > > versions.
> > > 2. OffsetNotAvailableException seems clear enough (i.e. we don't need the
> > > "ForPartition" part)
> >
> > Yeah, that is shorter and probably clearer. Changed.
> >
> > > 3. The KIP seems to be missing the compatibility section.
> >
> > Added.
> >
> > > 4. It would be good to mention that it's now possible for a fetch to
> > > succeed while list offsets will not for a period of time. And for older
> > > versions, the latter will return LeaderNotAvailable while the former
> > > would
> > > work fine, which is a bit unexpected. Not much we can do about it, but
> > > worth mentioning it in my opinion.
> >
> > Fair enough
> >
> > cheers,
> > Colin
> >
> > >
> > > Ismael
> > >
> > > On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> > >
> > > > Hi, Colin,
> > > >
> > > > Thanks for the KIP. +1. Just a minor comment. For the old client
> > requests,
> > > > would it be better to return a LEADER_NOT_AVAILABLE error instead?
> > > >
> > > > Jun
> > > >
> > > > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org>
> > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I'd like to start the voting process for KIP-207:The Offsets which
> > > > > ListOffsetsResponse returns should monotonically increase even
> > during a
> > > > > partition leader change.
> > > > >
> > > > > See
> > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > > > monotonically+increasing+even+during+a+partition+leader+change
> > > > > for details.
> > > > >
> > > > > The voting process will run for at least 72 hours.
> > > > >
> > > > > regards,
> > > > > Colin
> > > > >
> > > >
> >
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Jason Gustafson <ja...@confluent.io>.
Thanks for the KIP. I'm assuming the new behavior only affects ListOffsets
requests from the consumer. Might be worth mentioning that in the KIP.
Also, does it affect all ListOffsets requests, or only those that specify
the latest offset?
-Jason
On Wed, Oct 18, 2017 at 9:15 AM, Colin McCabe <cm...@apache.org> wrote:
> On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> > Thanks for the KIP, +1 (binding). A few comments:
> >
> > 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code for
> > older
> > versions.
> > 2. OffsetNotAvailableException seems clear enough (i.e. we don't need the
> > "ForPartition" part)
>
> Yeah, that is shorter and probably clearer. Changed.
>
> > 3. The KIP seems to be missing the compatibility section.
>
> Added.
>
> > 4. It would be good to mention that it's now possible for a fetch to
> > succeed while list offsets will not for a period of time. And for older
> > versions, the latter will return LeaderNotAvailable while the former
> > would
> > work fine, which is a bit unexpected. Not much we can do about it, but
> > worth mentioning it in my opinion.
>
> Fair enough
>
> cheers,
> Colin
>
> >
> > Ismael
> >
> > On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> >
> > > Hi, Colin,
> > >
> > > Thanks for the KIP. +1. Just a minor comment. For the old client
> requests,
> > > would it be better to return a LEADER_NOT_AVAILABLE error instead?
> > >
> > > Jun
> > >
> > > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org>
> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I'd like to start the voting process for KIP-207:The Offsets which
> > > > ListOffsetsResponse returns should monotonically increase even
> during a
> > > > partition leader change.
> > > >
> > > > See
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > > monotonically+increasing+even+during+a+partition+leader+change
> > > > for details.
> > > >
> > > > The voting process will run for at least 72 hours.
> > > >
> > > > regards,
> > > > Colin
> > > >
> > >
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns should
monotonically increase even during a partition leader change
Posted by Colin McCabe <cm...@apache.org>.
On Wed, Oct 18, 2017, at 04:09, Ismael Juma wrote:
> Thanks for the KIP, +1 (binding). A few comments:
>
> 1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code for
> older
> versions.
> 2. OffsetNotAvailableException seems clear enough (i.e. we don't need the
> "ForPartition" part)
Yeah, that is shorter and probably clearer. Changed.
> 3. The KIP seems to be missing the compatibility section.
Added.
> 4. It would be good to mention that it's now possible for a fetch to
> succeed while list offsets will not for a period of time. And for older
> versions, the latter will return LeaderNotAvailable while the former
> would
> work fine, which is a bit unexpected. Not much we can do about it, but
> worth mentioning it in my opinion.
Fair enough
cheers,
Colin
>
> Ismael
>
> On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
>
> > Hi, Colin,
> >
> > Thanks for the KIP. +1. Just a minor comment. For the old client requests,
> > would it be better to return a LEADER_NOT_AVAILABLE error instead?
> >
> > Jun
> >
> > On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org> wrote:
> >
> > > Hi all,
> > >
> > > I'd like to start the voting process for KIP-207:The Offsets which
> > > ListOffsetsResponse returns should monotonically increase even during a
> > > partition leader change.
> > >
> > > See
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > > monotonically+increasing+even+during+a+partition+leader+change
> > > for details.
> > >
> > > The voting process will run for at least 72 hours.
> > >
> > > regards,
> > > Colin
> > >
> >
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Ismael Juma <is...@juma.me.uk>.
Thanks for the KIP, +1 (binding). A few comments:
1. I agree with Jun about LEADER_NOT_AVAILABLE for the error code for older
versions.
2. OffsetNotAvailableException seems clear enough (i.e. we don't need the
"ForPartition" part)
3. The KIP seems to be missing the compatibility section.
4. It would be good to mention that it's now possible for a fetch to
succeed while list offsets will not for a period of time. And for older
versions, the latter will return LeaderNotAvailable while the former would
work fine, which is a bit unexpected. Not much we can do about it, but
worth mentioning it in my opinion.
Ismael
On Tue, Oct 17, 2017 at 9:26 PM, Jun Rao <ju...@confluent.io> wrote:
> Hi, Colin,
>
> Thanks for the KIP. +1. Just a minor comment. For the old client requests,
> would it be better to return a LEADER_NOT_AVAILABLE error instead?
>
> Jun
>
> On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org> wrote:
>
> > Hi all,
> >
> > I'd like to start the voting process for KIP-207:The Offsets which
> > ListOffsetsResponse returns should monotonically increase even during a
> > partition leader change.
> >
> > See
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> > monotonically+increasing+even+during+a+partition+leader+change
> > for details.
> >
> > The voting process will run for at least 72 hours.
> >
> > regards,
> > Colin
> >
>
Re: [VOTE] KIP-207:The Offsets which ListOffsetsResponse returns
should monotonically increase even during a partition leader change
Posted by Jun Rao <ju...@confluent.io>.
Hi, Colin,
Thanks for the KIP. +1. Just a minor comment. For the old client requests,
would it be better to return a LEADER_NOT_AVAILABLE error instead?
Jun
On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe <cm...@apache.org> wrote:
> Hi all,
>
> I'd like to start the voting process for KIP-207:The Offsets which
> ListOffsetsResponse returns should monotonically increase even during a
> partition leader change.
>
> See
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 207%3A+Offsets+returned+by+ListOffsetsResponse+should+be+
> monotonically+increasing+even+during+a+partition+leader+change
> for details.
>
> The voting process will run for at least 72 hours.
>
> regards,
> Colin
>