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
>
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
> wrote:
>
> >
Thanks for the KIP.
+1 (non-binding)
On Thu, Oct 26, 2017 at 5:58 AM, Jason Gustafson wrote:
> +1. Thanks for the KIP.
>
> On Mon, Oct 23, 2017 at 11:30 AM, Colin McCabe wrote:
>
> > On Mon, Oct 23, 2017, at 10:29, Jason Gustafson wrote:
> > > Thanks
+1. Thanks for the KIP.
On Mon, Oct 23, 2017 at 11:30 AM, Colin McCabe 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.
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
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
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)
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
>
>
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
+1 (non binding)
Thanks,
Satish.
On Wed, Oct 18, 2017 at 1:56 AM, 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?
>
> Jun
>
> On Tue, Oct 17, 2017
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 wrote:
> Hi all,
>
> I'd like to start the voting process for
+1
On Tue, Oct 17, 2017 at 11:23 AM, Apurva Mehta wrote:
> +1 (non-binding)
>
> On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe wrote:
>
> > Hi all,
> >
> > I'd like to start the voting process for KIP-207:The Offsets which
> > ListOffsetsResponse
+1 (non-binding)
On Tue, Oct 17, 2017 at 11:11 AM, Colin McCabe 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
>
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
14 matches
Mail list logo