You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by Pierre-Yves Ritschard <py...@spootnik.org> on 2016/01/26 10:00:19 UTC
[DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
KAFKA-3006 is under review, and would change some commonly used
signatures in the Kafka client library. The idea behind the proposal is
to provide a unified way of interacting with anything sequence like in
the client.
If the change is accepted, these would be the signatures that change:
void subscribe(Collection<String> topics);
void subscribe(Collection<String> topics, ConsumerRebalanceListener);
void assign(Collection<TopicPartition> partitions);
void pause(Collection<TopicPartition> partitions);
void resume(Collection<TopicPartition> partitions);
void seekToBeginning(Collection<TopicPartition>);
void seekToEnd(Collection<TopicPartition>);
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
Hi Ismael,
Thanks for the review, I will act on these a bit later today.
- pyr
Ismael Juma writes:
> Thanks Pierre. Including the dev mailing list.
>
> A few comments:
>
> 1. It's worth mentioning that the KafkaConsumer has the
> @InterfaceStability.Unstable annotation.
> 2. It would be good to show the existing signatures of the methods being
> changed before we show the changed signatures.
> 3. The proposed changes section mentions an alternative. I think the
> alternative should be moved to the "Rejected Alternatives" section.
> 4. It would be good to explain why `Collection` was chosen specifically for
> the parameters (as opposed to `Iterable` for example).\
> 5. Finally, it would be good to explain why we decided to change the method
> parameters instead of the return types (or why we should not change the
> return types).
>
> Hopefully it should be straightforward to address these points.
>
> Thanks,
> Ismael
>
> On Tue, Jan 26, 2016 at 9:00 AM, Pierre-Yves Ritschard <py...@spootnik.org>
> wrote:
>
>>
>> KAFKA-3006 is under review, and would change some commonly used
>> signatures in the Kafka client library. The idea behind the proposal is
>> to provide a unified way of interacting with anything sequence like in
>> the client.
>>
>> If the change is accepted, these would be the signatures that change:
>>
>> void subscribe(Collection<String> topics);
>> void subscribe(Collection<String> topics, ConsumerRebalanceListener);
>> void assign(Collection<TopicPartition> partitions);
>> void pause(Collection<TopicPartition> partitions);
>> void resume(Collection<TopicPartition> partitions);
>> void seekToBeginning(Collection<TopicPartition>);
>> void seekToEnd(Collection<TopicPartition>);
>>
>>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Hi Pierre and Jason,
A comment below.
On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io> wrote:
> Hi Pierre,
>
> Thanks for your persistence on this issue. I've gone back and forth on this
> a few times. The current API can definitely be annoying in some cases, but
> breaking compatibility still sucks. We do have the @Unstable annotation on
> the API, but it's unclear what exactly it means and I'm guessing most users
> haven't even noticed it. In the end, I feel we should try harder to keep
> compatibility even if it means keeping some of the annoying usage. As an
> alternative, maybe we could do the following:
>
> 1. For subscribe() and assign(), change the parameter type to collection as
> planned in the KIP. This is at least source-compatible, so as long as users
> compile against the updated release, there shouldn't be any problems.
>
> 2. Instead of changing the signatures of the current pause/resume/seek
> APIs, maybe we can overload them. This keeps compatibility and supports the
> more convenient collection usage, but the cost is some API bloat.
>
What if we deprecate the existing pause/resume/seek APIs in favour of the
new overloads? That would give us compatibility between 0.9.0.x and 0.9.1.x
while giving us the option of removing those methods in a future release.
Ismael
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
A good compromise would be to add an arity with a single TopicPartition.
Jason Gustafson writes:
> Most of the use cases of pause/resume that I've seen work only on single
> partitions (e.g in Kafka Streams), so the current varargs method is kind of
> nice. It would also be nice to be able to do the following:
>
> consumer.pause(consumer.assignment());
>
> Both variants seem convenient in different situations.
>
> -Jason
>
> On Wed, Feb 3, 2016 at 6:34 AM, Ismael Juma <is...@juma.me.uk> wrote:
>
>> Hi Becket,
>>
>> On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin <be...@gmail.com> wrote:
>>
>> > 2. For seek(), pause(), resume(), it depends on how easily user can use
>> > them.
>> > If we take current interface, and user have a list of partitions to
>> > pause(), what they can do is something like:
>> > pause(patitionList.toArray());
>> > If we change that to take a collection and user have only one
>> partition
>> > to pause. They have to do:
>> > pause(new List<>(partition));
>> > Personally I think the current interface handles both single
>> partition
>> > and a list of partitions better. It is not ideal that we have to adapt to
>> > the interface. I just feel it is weirder to create a new list.
>> >
>>
>> This is not quite right. `toArray` returns an `Object[]`, you would need
>> the more verbose:
>>
>> consumer.pause(partitionList.toArray(new TopicPartition[0]));
>>
>> And for the other case, the recommended approach would be:
>>
>> consumer.assign(Collections.singleton(partition));
>>
>> Or, more concisely (with a static import):
>>
>> consumer.assign(singletonList(partition));
>>
>> Do people often call `seek()`, `pause()` and `resume()` with a single
>> partition?
>>
>> Ismael
>>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
Most of the use cases of pause/resume that I've seen work only on single
partitions (e.g in Kafka Streams), so the current varargs method is kind of
nice. It would also be nice to be able to do the following:
consumer.pause(consumer.assignment());
Both variants seem convenient in different situations.
-Jason
On Wed, Feb 3, 2016 at 6:34 AM, Ismael Juma <is...@juma.me.uk> wrote:
> Hi Becket,
>
> On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin <be...@gmail.com> wrote:
>
> > 2. For seek(), pause(), resume(), it depends on how easily user can use
> > them.
> > If we take current interface, and user have a list of partitions to
> > pause(), what they can do is something like:
> > pause(patitionList.toArray());
> > If we change that to take a collection and user have only one
> partition
> > to pause. They have to do:
> > pause(new List<>(partition));
> > Personally I think the current interface handles both single
> partition
> > and a list of partitions better. It is not ideal that we have to adapt to
> > the interface. I just feel it is weirder to create a new list.
> >
>
> This is not quite right. `toArray` returns an `Object[]`, you would need
> the more verbose:
>
> consumer.pause(partitionList.toArray(new TopicPartition[0]));
>
> And for the other case, the recommended approach would be:
>
> consumer.assign(Collections.singleton(partition));
>
> Or, more concisely (with a static import):
>
> consumer.assign(singletonList(partition));
>
> Do people often call `seek()`, `pause()` and `resume()` with a single
> partition?
>
> Ismael
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
Most of the use cases of pause/resume that I've seen work only on single
partitions (e.g in Kafka Streams), so the current varargs method is kind of
nice. It would also be nice to be able to do the following:
consumer.pause(consumer.assignment());
Both variants seem convenient in different situations.
-Jason
On Wed, Feb 3, 2016 at 6:34 AM, Ismael Juma <is...@juma.me.uk> wrote:
> Hi Becket,
>
> On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin <be...@gmail.com> wrote:
>
> > 2. For seek(), pause(), resume(), it depends on how easily user can use
> > them.
> > If we take current interface, and user have a list of partitions to
> > pause(), what they can do is something like:
> > pause(patitionList.toArray());
> > If we change that to take a collection and user have only one
> partition
> > to pause. They have to do:
> > pause(new List<>(partition));
> > Personally I think the current interface handles both single
> partition
> > and a list of partitions better. It is not ideal that we have to adapt to
> > the interface. I just feel it is weirder to create a new list.
> >
>
> This is not quite right. `toArray` returns an `Object[]`, you would need
> the more verbose:
>
> consumer.pause(partitionList.toArray(new TopicPartition[0]));
>
> And for the other case, the recommended approach would be:
>
> consumer.assign(Collections.singleton(partition));
>
> Or, more concisely (with a static import):
>
> consumer.assign(singletonList(partition));
>
> Do people often call `seek()`, `pause()` and `resume()` with a single
> partition?
>
> Ismael
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Hi Becket,
On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin <be...@gmail.com> wrote:
> 2. For seek(), pause(), resume(), it depends on how easily user can use
> them.
> If we take current interface, and user have a list of partitions to
> pause(), what they can do is something like:
> pause(patitionList.toArray());
> If we change that to take a collection and user have only one partition
> to pause. They have to do:
> pause(new List<>(partition));
> Personally I think the current interface handles both single partition
> and a list of partitions better. It is not ideal that we have to adapt to
> the interface. I just feel it is weirder to create a new list.
>
This is not quite right. `toArray` returns an `Object[]`, you would need
the more verbose:
consumer.pause(partitionList.toArray(new TopicPartition[0]));
And for the other case, the recommended approach would be:
consumer.assign(Collections.singleton(partition));
Or, more concisely (with a static import):
consumer.assign(singletonList(partition));
Do people often call `seek()`, `pause()` and `resume()` with a single
partition?
Ismael
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Hi Becket,
On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin <be...@gmail.com> wrote:
> 2. For seek(), pause(), resume(), it depends on how easily user can use
> them.
> If we take current interface, and user have a list of partitions to
> pause(), what they can do is something like:
> pause(patitionList.toArray());
> If we change that to take a collection and user have only one partition
> to pause. They have to do:
> pause(new List<>(partition));
> Personally I think the current interface handles both single partition
> and a list of partitions better. It is not ideal that we have to adapt to
> the interface. I just feel it is weirder to create a new list.
>
This is not quite right. `toArray` returns an `Object[]`, you would need
the more verbose:
consumer.pause(partitionList.toArray(new TopicPartition[0]));
And for the other case, the recommended approach would be:
consumer.assign(Collections.singleton(partition));
Or, more concisely (with a static import):
consumer.assign(singletonList(partition));
Do people often call `seek()`, `pause()` and `resume()` with a single
partition?
Ismael
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Becket Qin <be...@gmail.com>.
>From the user code I see that uses the new consumer API so far, here are my
two cents:
1. For subscribe() and assign(), because we are doing an replacement,
taking either a List() or Collection() makes sense.
2. For seek(), pause(), resume(), it depends on how easily user can use
them.
If we take current interface, and user have a list of partitions to
pause(), what they can do is something like:
pause(patitionList.toArray());
If we change that to take a collection and user have only one partition
to pause. They have to do:
pause(new List<>(partition));
Personally I think the current interface handles both single partition
and a list of partitions better. It is not ideal that we have to adapt to
the interface. I just feel it is weirder to create a new list.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jan 27, 2016 at 2:24 PM, Gwen Shapira <gw...@confluent.io> wrote:
> I have a minor preference toward modifying the API.
> Because it is source-compatible and protocol-compatible, the only case that
> will break is if you use client code from one version but run with a JAR
> from a different version, which sounds like a pretty weird setup in
> general.
>
> Its not a strong preference though, I'll vote for either.
>
> On Wed, Jan 27, 2016 at 1:35 PM, Pierre-Yves Ritschard <py...@spootnik.org>
> wrote:
>
> >
> > Hi Jason,
> >
> > Thanks for weighing in on this. Here's my take:
> >
> > - I initially opted for overloading, but this met resistance (most
> > vocally from Jay Kreps). I don't have strong feelings either way (I
> > tend to prefer the current proposal without overloading but would
> > understand the need to add it back).
> > - The feedback I got around me (from an admittedly small population
> > sample) is that most people are thinking of migrating to 0.9.0.0. I
> > would wager that a very large majority of users are running production
> > apps on 0.8 clients and would thus not be impacted. The very recent
> > availability of the client libs would also indicate that those having
> > already switched to 0.9.0.0 client libs have a capacity to iterate
> fast.
> >
> > Jason Gustafson writes:
> >
> > > Hi Pierre,
> > >
> > > Thanks for your persistence on this issue. I've gone back and forth on
> > this
> > > a few times. The current API can definitely be annoying in some cases,
> > but
> > > breaking compatibility still sucks. We do have the @Unstable annotation
> > on
> > > the API, but it's unclear what exactly it means and I'm guessing most
> > users
> > > haven't even noticed it. In the end, I feel we should try harder to
> keep
> > > compatibility even if it means keeping some of the annoying usage. As
> an
> > > alternative, maybe we could do the following:
> > >
> > > 1. For subscribe() and assign(), change the parameter type to
> collection
> > as
> > > planned in the KIP. This is at least source-compatible, so as long as
> > users
> > > compile against the updated release, there shouldn't be any problems.
> > >
> > > 2. Instead of changing the signatures of the current pause/resume/seek
> > > APIs, maybe we can overload them. This keeps compatibility and supports
> > the
> > > more convenient collection usage, but the cost is some API bloat.
> > >
> > > In my opinion, the slightly increased surface area from overloading is
> > > worth the cost of keeping compatibility. Overloading is very common in
> > Java
> > > APIs, so there's no potential for confusion, and it has basically no
> > > maintenance overhead. However, I know others already expressed
> opposition
> > > to this, so if it's not agreeable, then I'm probably more inclined to
> > keep
> > > the current API. That said, it's not a strong preference. If the
> > consensus
> > > is to allow the breakage now, it doesn't seem like too big of a deal
> for
> > > users to update their code. It might be early enough that most users
> > > haven't finished (or perhaps haven't even started) migrating their code
> > to
> > > use the new consumer.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Jason
> > >
> > >
> > > On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <
> > pyr@spootnik.org>
> > > wrote:
> > >
> > >>
> > >> I updated the KIP accordingly.
> > >>
> > >> Cheers,
> > >> - pyr
> > >>
> >
> >
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Becket Qin <be...@gmail.com>.
>From the user code I see that uses the new consumer API so far, here are my
two cents:
1. For subscribe() and assign(), because we are doing an replacement,
taking either a List() or Collection() makes sense.
2. For seek(), pause(), resume(), it depends on how easily user can use
them.
If we take current interface, and user have a list of partitions to
pause(), what they can do is something like:
pause(patitionList.toArray());
If we change that to take a collection and user have only one partition
to pause. They have to do:
pause(new List<>(partition));
Personally I think the current interface handles both single partition
and a list of partitions better. It is not ideal that we have to adapt to
the interface. I just feel it is weirder to create a new list.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jan 27, 2016 at 2:24 PM, Gwen Shapira <gw...@confluent.io> wrote:
> I have a minor preference toward modifying the API.
> Because it is source-compatible and protocol-compatible, the only case that
> will break is if you use client code from one version but run with a JAR
> from a different version, which sounds like a pretty weird setup in
> general.
>
> Its not a strong preference though, I'll vote for either.
>
> On Wed, Jan 27, 2016 at 1:35 PM, Pierre-Yves Ritschard <py...@spootnik.org>
> wrote:
>
> >
> > Hi Jason,
> >
> > Thanks for weighing in on this. Here's my take:
> >
> > - I initially opted for overloading, but this met resistance (most
> > vocally from Jay Kreps). I don't have strong feelings either way (I
> > tend to prefer the current proposal without overloading but would
> > understand the need to add it back).
> > - The feedback I got around me (from an admittedly small population
> > sample) is that most people are thinking of migrating to 0.9.0.0. I
> > would wager that a very large majority of users are running production
> > apps on 0.8 clients and would thus not be impacted. The very recent
> > availability of the client libs would also indicate that those having
> > already switched to 0.9.0.0 client libs have a capacity to iterate
> fast.
> >
> > Jason Gustafson writes:
> >
> > > Hi Pierre,
> > >
> > > Thanks for your persistence on this issue. I've gone back and forth on
> > this
> > > a few times. The current API can definitely be annoying in some cases,
> > but
> > > breaking compatibility still sucks. We do have the @Unstable annotation
> > on
> > > the API, but it's unclear what exactly it means and I'm guessing most
> > users
> > > haven't even noticed it. In the end, I feel we should try harder to
> keep
> > > compatibility even if it means keeping some of the annoying usage. As
> an
> > > alternative, maybe we could do the following:
> > >
> > > 1. For subscribe() and assign(), change the parameter type to
> collection
> > as
> > > planned in the KIP. This is at least source-compatible, so as long as
> > users
> > > compile against the updated release, there shouldn't be any problems.
> > >
> > > 2. Instead of changing the signatures of the current pause/resume/seek
> > > APIs, maybe we can overload them. This keeps compatibility and supports
> > the
> > > more convenient collection usage, but the cost is some API bloat.
> > >
> > > In my opinion, the slightly increased surface area from overloading is
> > > worth the cost of keeping compatibility. Overloading is very common in
> > Java
> > > APIs, so there's no potential for confusion, and it has basically no
> > > maintenance overhead. However, I know others already expressed
> opposition
> > > to this, so if it's not agreeable, then I'm probably more inclined to
> > keep
> > > the current API. That said, it's not a strong preference. If the
> > consensus
> > > is to allow the breakage now, it doesn't seem like too big of a deal
> for
> > > users to update their code. It might be early enough that most users
> > > haven't finished (or perhaps haven't even started) migrating their code
> > to
> > > use the new consumer.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Jason
> > >
> > >
> > > On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <
> > pyr@spootnik.org>
> > > wrote:
> > >
> > >>
> > >> I updated the KIP accordingly.
> > >>
> > >> Cheers,
> > >> - pyr
> > >>
> >
> >
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Gwen Shapira <gw...@confluent.io>.
I have a minor preference toward modifying the API.
Because it is source-compatible and protocol-compatible, the only case that
will break is if you use client code from one version but run with a JAR
from a different version, which sounds like a pretty weird setup in general.
Its not a strong preference though, I'll vote for either.
On Wed, Jan 27, 2016 at 1:35 PM, Pierre-Yves Ritschard <py...@spootnik.org>
wrote:
>
> Hi Jason,
>
> Thanks for weighing in on this. Here's my take:
>
> - I initially opted for overloading, but this met resistance (most
> vocally from Jay Kreps). I don't have strong feelings either way (I
> tend to prefer the current proposal without overloading but would
> understand the need to add it back).
> - The feedback I got around me (from an admittedly small population
> sample) is that most people are thinking of migrating to 0.9.0.0. I
> would wager that a very large majority of users are running production
> apps on 0.8 clients and would thus not be impacted. The very recent
> availability of the client libs would also indicate that those having
> already switched to 0.9.0.0 client libs have a capacity to iterate fast.
>
> Jason Gustafson writes:
>
> > Hi Pierre,
> >
> > Thanks for your persistence on this issue. I've gone back and forth on
> this
> > a few times. The current API can definitely be annoying in some cases,
> but
> > breaking compatibility still sucks. We do have the @Unstable annotation
> on
> > the API, but it's unclear what exactly it means and I'm guessing most
> users
> > haven't even noticed it. In the end, I feel we should try harder to keep
> > compatibility even if it means keeping some of the annoying usage. As an
> > alternative, maybe we could do the following:
> >
> > 1. For subscribe() and assign(), change the parameter type to collection
> as
> > planned in the KIP. This is at least source-compatible, so as long as
> users
> > compile against the updated release, there shouldn't be any problems.
> >
> > 2. Instead of changing the signatures of the current pause/resume/seek
> > APIs, maybe we can overload them. This keeps compatibility and supports
> the
> > more convenient collection usage, but the cost is some API bloat.
> >
> > In my opinion, the slightly increased surface area from overloading is
> > worth the cost of keeping compatibility. Overloading is very common in
> Java
> > APIs, so there's no potential for confusion, and it has basically no
> > maintenance overhead. However, I know others already expressed opposition
> > to this, so if it's not agreeable, then I'm probably more inclined to
> keep
> > the current API. That said, it's not a strong preference. If the
> consensus
> > is to allow the breakage now, it doesn't seem like too big of a deal for
> > users to update their code. It might be early enough that most users
> > haven't finished (or perhaps haven't even started) migrating their code
> to
> > use the new consumer.
> >
> > What do you think?
> >
> > Thanks,
> > Jason
> >
> >
> > On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <
> pyr@spootnik.org>
> > wrote:
> >
> >>
> >> I updated the KIP accordingly.
> >>
> >> Cheers,
> >> - pyr
> >>
>
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Gwen Shapira <gw...@confluent.io>.
I have a minor preference toward modifying the API.
Because it is source-compatible and protocol-compatible, the only case that
will break is if you use client code from one version but run with a JAR
from a different version, which sounds like a pretty weird setup in general.
Its not a strong preference though, I'll vote for either.
On Wed, Jan 27, 2016 at 1:35 PM, Pierre-Yves Ritschard <py...@spootnik.org>
wrote:
>
> Hi Jason,
>
> Thanks for weighing in on this. Here's my take:
>
> - I initially opted for overloading, but this met resistance (most
> vocally from Jay Kreps). I don't have strong feelings either way (I
> tend to prefer the current proposal without overloading but would
> understand the need to add it back).
> - The feedback I got around me (from an admittedly small population
> sample) is that most people are thinking of migrating to 0.9.0.0. I
> would wager that a very large majority of users are running production
> apps on 0.8 clients and would thus not be impacted. The very recent
> availability of the client libs would also indicate that those having
> already switched to 0.9.0.0 client libs have a capacity to iterate fast.
>
> Jason Gustafson writes:
>
> > Hi Pierre,
> >
> > Thanks for your persistence on this issue. I've gone back and forth on
> this
> > a few times. The current API can definitely be annoying in some cases,
> but
> > breaking compatibility still sucks. We do have the @Unstable annotation
> on
> > the API, but it's unclear what exactly it means and I'm guessing most
> users
> > haven't even noticed it. In the end, I feel we should try harder to keep
> > compatibility even if it means keeping some of the annoying usage. As an
> > alternative, maybe we could do the following:
> >
> > 1. For subscribe() and assign(), change the parameter type to collection
> as
> > planned in the KIP. This is at least source-compatible, so as long as
> users
> > compile against the updated release, there shouldn't be any problems.
> >
> > 2. Instead of changing the signatures of the current pause/resume/seek
> > APIs, maybe we can overload them. This keeps compatibility and supports
> the
> > more convenient collection usage, but the cost is some API bloat.
> >
> > In my opinion, the slightly increased surface area from overloading is
> > worth the cost of keeping compatibility. Overloading is very common in
> Java
> > APIs, so there's no potential for confusion, and it has basically no
> > maintenance overhead. However, I know others already expressed opposition
> > to this, so if it's not agreeable, then I'm probably more inclined to
> keep
> > the current API. That said, it's not a strong preference. If the
> consensus
> > is to allow the breakage now, it doesn't seem like too big of a deal for
> > users to update their code. It might be early enough that most users
> > haven't finished (or perhaps haven't even started) migrating their code
> to
> > use the new consumer.
> >
> > What do you think?
> >
> > Thanks,
> > Jason
> >
> >
> > On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <
> pyr@spootnik.org>
> > wrote:
> >
> >>
> >> I updated the KIP accordingly.
> >>
> >> Cheers,
> >> - pyr
> >>
>
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
Hi Jason,
Thanks for weighing in on this. Here's my take:
- I initially opted for overloading, but this met resistance (most
vocally from Jay Kreps). I don't have strong feelings either way (I
tend to prefer the current proposal without overloading but would
understand the need to add it back).
- The feedback I got around me (from an admittedly small population
sample) is that most people are thinking of migrating to 0.9.0.0. I
would wager that a very large majority of users are running production
apps on 0.8 clients and would thus not be impacted. The very recent
availability of the client libs would also indicate that those having
already switched to 0.9.0.0 client libs have a capacity to iterate fast.
Jason Gustafson writes:
> Hi Pierre,
>
> Thanks for your persistence on this issue. I've gone back and forth on this
> a few times. The current API can definitely be annoying in some cases, but
> breaking compatibility still sucks. We do have the @Unstable annotation on
> the API, but it's unclear what exactly it means and I'm guessing most users
> haven't even noticed it. In the end, I feel we should try harder to keep
> compatibility even if it means keeping some of the annoying usage. As an
> alternative, maybe we could do the following:
>
> 1. For subscribe() and assign(), change the parameter type to collection as
> planned in the KIP. This is at least source-compatible, so as long as users
> compile against the updated release, there shouldn't be any problems.
>
> 2. Instead of changing the signatures of the current pause/resume/seek
> APIs, maybe we can overload them. This keeps compatibility and supports the
> more convenient collection usage, but the cost is some API bloat.
>
> In my opinion, the slightly increased surface area from overloading is
> worth the cost of keeping compatibility. Overloading is very common in Java
> APIs, so there's no potential for confusion, and it has basically no
> maintenance overhead. However, I know others already expressed opposition
> to this, so if it's not agreeable, then I'm probably more inclined to keep
> the current API. That said, it's not a strong preference. If the consensus
> is to allow the breakage now, it doesn't seem like too big of a deal for
> users to update their code. It might be early enough that most users
> haven't finished (or perhaps haven't even started) migrating their code to
> use the new consumer.
>
> What do you think?
>
> Thanks,
> Jason
>
>
> On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <py...@spootnik.org>
> wrote:
>
>>
>> I updated the KIP accordingly.
>>
>> Cheers,
>> - pyr
>>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Hi Pierre and Jason,
A comment below.
On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io> wrote:
> Hi Pierre,
>
> Thanks for your persistence on this issue. I've gone back and forth on this
> a few times. The current API can definitely be annoying in some cases, but
> breaking compatibility still sucks. We do have the @Unstable annotation on
> the API, but it's unclear what exactly it means and I'm guessing most users
> haven't even noticed it. In the end, I feel we should try harder to keep
> compatibility even if it means keeping some of the annoying usage. As an
> alternative, maybe we could do the following:
>
> 1. For subscribe() and assign(), change the parameter type to collection as
> planned in the KIP. This is at least source-compatible, so as long as users
> compile against the updated release, there shouldn't be any problems.
>
> 2. Instead of changing the signatures of the current pause/resume/seek
> APIs, maybe we can overload them. This keeps compatibility and supports the
> more convenient collection usage, but the cost is some API bloat.
>
What if we deprecate the existing pause/resume/seek APIs in favour of the
new overloads? That would give us compatibility between 0.9.0.x and 0.9.1.x
while giving us the option of removing those methods in a future release.
Ismael
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Becket Qin <be...@gmail.com>.
Hi Jason,
Yes, 0.9 clients should still work with 0.10 brokers.
Thanks,
Jiangjie (Becket) Qin
On Mon, Mar 7, 2016 at 4:10 PM, Jason Gustafson <ja...@confluent.io> wrote:
> +users
>
> On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > Hey Ismael,
> >
> > Thanks for bringing this up again. Just a quick question: if we do #1,
> > then there's no way that a user binary could work against both 0.9 and
> 0.10
> > of kafka-clients, right? I'm not sure if that is much of a problem, but
> may
> > cause a little pain if a user somehow depends transitively on different
> > versions. Excluding this change, would we otherwise expect
> > kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> > KIP-32 continued to support the old message format, but I could be wrong.
> >
> > -Jason
> >
> > On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> >> Coming back to this, see below.
> >>
> >> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
> >> wrote:
> >>
> >> >
> >> > 1. For subscribe() and assign(), change the parameter type to
> >> collection as
> >> > planned in the KIP. This is at least source-compatible, so as long as
> >> users
> >> > compile against the updated release, there shouldn't be any problems.
> >> >
> >>
> >> I think this one seems to be the least controversial part of the
> proposal.
> >> And I agree with this suggestion.
> >>
> >> 2. Instead of changing the signatures of the current pause/resume/seek
> >> > APIs, maybe we can overload them. This keeps compatibility and
> supports
> >> the
> >> > more convenient collection usage, but the cost is some API bloat.
> >> >
> >>
> >> It seems like there is no clear winner, so I am OK with this too.
> >>
> >> Given the release plan for 0.10.0.0 that is being voted on, I think we
> >> should make a decision on this one way or another very soon.
> >>
> >> Ismael
> >>
> >
> >
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Becket Qin <be...@gmail.com>.
Hi Jason,
Yes, 0.9 clients should still work with 0.10 brokers.
Thanks,
Jiangjie (Becket) Qin
On Mon, Mar 7, 2016 at 4:10 PM, Jason Gustafson <ja...@confluent.io> wrote:
> +users
>
> On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > Hey Ismael,
> >
> > Thanks for bringing this up again. Just a quick question: if we do #1,
> > then there's no way that a user binary could work against both 0.9 and
> 0.10
> > of kafka-clients, right? I'm not sure if that is much of a problem, but
> may
> > cause a little pain if a user somehow depends transitively on different
> > versions. Excluding this change, would we otherwise expect
> > kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> > KIP-32 continued to support the old message format, but I could be wrong.
> >
> > -Jason
> >
> > On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> >> Coming back to this, see below.
> >>
> >> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
> >> wrote:
> >>
> >> >
> >> > 1. For subscribe() and assign(), change the parameter type to
> >> collection as
> >> > planned in the KIP. This is at least source-compatible, so as long as
> >> users
> >> > compile against the updated release, there shouldn't be any problems.
> >> >
> >>
> >> I think this one seems to be the least controversial part of the
> proposal.
> >> And I agree with this suggestion.
> >>
> >> 2. Instead of changing the signatures of the current pause/resume/seek
> >> > APIs, maybe we can overload them. This keeps compatibility and
> supports
> >> the
> >> > more convenient collection usage, but the cost is some API bloat.
> >> >
> >>
> >> It seems like there is no clear winner, so I am OK with this too.
> >>
> >> Given the release plan for 0.10.0.0 that is being voted on, I think we
> >> should make a decision on this one way or another very soon.
> >>
> >> Ismael
> >>
> >
> >
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
+users
On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io> wrote:
> Hey Ismael,
>
> Thanks for bringing this up again. Just a quick question: if we do #1,
> then there's no way that a user binary could work against both 0.9 and 0.10
> of kafka-clients, right? I'm not sure if that is much of a problem, but may
> cause a little pain if a user somehow depends transitively on different
> versions. Excluding this change, would we otherwise expect
> kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> KIP-32 continued to support the old message format, but I could be wrong.
>
> -Jason
>
> On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
>> Coming back to this, see below.
>>
>> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
>> wrote:
>>
>> >
>> > 1. For subscribe() and assign(), change the parameter type to
>> collection as
>> > planned in the KIP. This is at least source-compatible, so as long as
>> users
>> > compile against the updated release, there shouldn't be any problems.
>> >
>>
>> I think this one seems to be the least controversial part of the proposal.
>> And I agree with this suggestion.
>>
>> 2. Instead of changing the signatures of the current pause/resume/seek
>> > APIs, maybe we can overload them. This keeps compatibility and supports
>> the
>> > more convenient collection usage, but the cost is some API bloat.
>> >
>>
>> It seems like there is no clear winner, so I am OK with this too.
>>
>> Given the release plan for 0.10.0.0 that is being voted on, I think we
>> should make a decision on this one way or another very soon.
>>
>> Ismael
>>
>
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
+users
On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io> wrote:
> Hey Ismael,
>
> Thanks for bringing this up again. Just a quick question: if we do #1,
> then there's no way that a user binary could work against both 0.9 and 0.10
> of kafka-clients, right? I'm not sure if that is much of a problem, but may
> cause a little pain if a user somehow depends transitively on different
> versions. Excluding this change, would we otherwise expect
> kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> KIP-32 continued to support the old message format, but I could be wrong.
>
> -Jason
>
> On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
>> Coming back to this, see below.
>>
>> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
>> wrote:
>>
>> >
>> > 1. For subscribe() and assign(), change the parameter type to
>> collection as
>> > planned in the KIP. This is at least source-compatible, so as long as
>> users
>> > compile against the updated release, there shouldn't be any problems.
>> >
>>
>> I think this one seems to be the least controversial part of the proposal.
>> And I agree with this suggestion.
>>
>> 2. Instead of changing the signatures of the current pause/resume/seek
>> > APIs, maybe we can overload them. This keeps compatibility and supports
>> the
>> > more convenient collection usage, but the cost is some API bloat.
>> >
>>
>> It seems like there is no clear winner, so I am OK with this too.
>>
>> Given the release plan for 0.10.0.0 that is being voted on, I think we
>> should make a decision on this one way or another very soon.
>>
>> Ismael
>>
>
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
Hey Ismael,
Thanks for bringing this up again. Just a quick question: if we do #1, then
there's no way that a user binary could work against both 0.9 and 0.10 of
kafka-clients, right? I'm not sure if that is much of a problem, but may
cause a little pain if a user somehow depends transitively on different
versions. Excluding this change, would we otherwise expect
kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
KIP-32 continued to support the old message format, but I could be wrong.
-Jason
On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
> Coming back to this, see below.
>
> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> >
> > 1. For subscribe() and assign(), change the parameter type to collection
> as
> > planned in the KIP. This is at least source-compatible, so as long as
> users
> > compile against the updated release, there shouldn't be any problems.
> >
>
> I think this one seems to be the least controversial part of the proposal.
> And I agree with this suggestion.
>
> 2. Instead of changing the signatures of the current pause/resume/seek
> > APIs, maybe we can overload them. This keeps compatibility and supports
> the
> > more convenient collection usage, but the cost is some API bloat.
> >
>
> It seems like there is no clear winner, so I am OK with this too.
>
> Given the release plan for 0.10.0.0 that is being voted on, I think we
> should make a decision on this one way or another very soon.
>
> Ismael
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Coming back to this, see below.
On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io> wrote:
>
> 1. For subscribe() and assign(), change the parameter type to collection as
> planned in the KIP. This is at least source-compatible, so as long as users
> compile against the updated release, there shouldn't be any problems.
>
I think this one seems to be the least controversial part of the proposal.
And I agree with this suggestion.
2. Instead of changing the signatures of the current pause/resume/seek
> APIs, maybe we can overload them. This keeps compatibility and supports the
> more convenient collection usage, but the cost is some API bloat.
>
It seems like there is no clear winner, so I am OK with this too.
Given the release plan for 0.10.0.0 that is being voted on, I think we
should make a decision on this one way or another very soon.
Ismael
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
Hi Jason,
Thanks for weighing in on this. Here's my take:
- I initially opted for overloading, but this met resistance (most
vocally from Jay Kreps). I don't have strong feelings either way (I
tend to prefer the current proposal without overloading but would
understand the need to add it back).
- The feedback I got around me (from an admittedly small population
sample) is that most people are thinking of migrating to 0.9.0.0. I
would wager that a very large majority of users are running production
apps on 0.8 clients and would thus not be impacted. The very recent
availability of the client libs would also indicate that those having
already switched to 0.9.0.0 client libs have a capacity to iterate fast.
Jason Gustafson writes:
> Hi Pierre,
>
> Thanks for your persistence on this issue. I've gone back and forth on this
> a few times. The current API can definitely be annoying in some cases, but
> breaking compatibility still sucks. We do have the @Unstable annotation on
> the API, but it's unclear what exactly it means and I'm guessing most users
> haven't even noticed it. In the end, I feel we should try harder to keep
> compatibility even if it means keeping some of the annoying usage. As an
> alternative, maybe we could do the following:
>
> 1. For subscribe() and assign(), change the parameter type to collection as
> planned in the KIP. This is at least source-compatible, so as long as users
> compile against the updated release, there shouldn't be any problems.
>
> 2. Instead of changing the signatures of the current pause/resume/seek
> APIs, maybe we can overload them. This keeps compatibility and supports the
> more convenient collection usage, but the cost is some API bloat.
>
> In my opinion, the slightly increased surface area from overloading is
> worth the cost of keeping compatibility. Overloading is very common in Java
> APIs, so there's no potential for confusion, and it has basically no
> maintenance overhead. However, I know others already expressed opposition
> to this, so if it's not agreeable, then I'm probably more inclined to keep
> the current API. That said, it's not a strong preference. If the consensus
> is to allow the breakage now, it doesn't seem like too big of a deal for
> users to update their code. It might be early enough that most users
> haven't finished (or perhaps haven't even started) migrating their code to
> use the new consumer.
>
> What do you think?
>
> Thanks,
> Jason
>
>
> On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <py...@spootnik.org>
> wrote:
>
>>
>> I updated the KIP accordingly.
>>
>> Cheers,
>> - pyr
>>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Coming back to this, see below.
On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io> wrote:
>
> 1. For subscribe() and assign(), change the parameter type to collection as
> planned in the KIP. This is at least source-compatible, so as long as users
> compile against the updated release, there shouldn't be any problems.
>
I think this one seems to be the least controversial part of the proposal.
And I agree with this suggestion.
2. Instead of changing the signatures of the current pause/resume/seek
> APIs, maybe we can overload them. This keeps compatibility and supports the
> more convenient collection usage, but the cost is some API bloat.
>
It seems like there is no clear winner, so I am OK with this too.
Given the release plan for 0.10.0.0 that is being voted on, I think we
should make a decision on this one way or another very soon.
Ismael
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
Hi Pierre,
Thanks for your persistence on this issue. I've gone back and forth on this
a few times. The current API can definitely be annoying in some cases, but
breaking compatibility still sucks. We do have the @Unstable annotation on
the API, but it's unclear what exactly it means and I'm guessing most users
haven't even noticed it. In the end, I feel we should try harder to keep
compatibility even if it means keeping some of the annoying usage. As an
alternative, maybe we could do the following:
1. For subscribe() and assign(), change the parameter type to collection as
planned in the KIP. This is at least source-compatible, so as long as users
compile against the updated release, there shouldn't be any problems.
2. Instead of changing the signatures of the current pause/resume/seek
APIs, maybe we can overload them. This keeps compatibility and supports the
more convenient collection usage, but the cost is some API bloat.
In my opinion, the slightly increased surface area from overloading is
worth the cost of keeping compatibility. Overloading is very common in Java
APIs, so there's no potential for confusion, and it has basically no
maintenance overhead. However, I know others already expressed opposition
to this, so if it's not agreeable, then I'm probably more inclined to keep
the current API. That said, it's not a strong preference. If the consensus
is to allow the breakage now, it doesn't seem like too big of a deal for
users to update their code. It might be early enough that most users
haven't finished (or perhaps haven't even started) migrating their code to
use the new consumer.
What do you think?
Thanks,
Jason
On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <py...@spootnik.org>
wrote:
>
> I updated the KIP accordingly.
>
> Cheers,
> - pyr
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Jason Gustafson <ja...@confluent.io>.
Hi Pierre,
Thanks for your persistence on this issue. I've gone back and forth on this
a few times. The current API can definitely be annoying in some cases, but
breaking compatibility still sucks. We do have the @Unstable annotation on
the API, but it's unclear what exactly it means and I'm guessing most users
haven't even noticed it. In the end, I feel we should try harder to keep
compatibility even if it means keeping some of the annoying usage. As an
alternative, maybe we could do the following:
1. For subscribe() and assign(), change the parameter type to collection as
planned in the KIP. This is at least source-compatible, so as long as users
compile against the updated release, there shouldn't be any problems.
2. Instead of changing the signatures of the current pause/resume/seek
APIs, maybe we can overload them. This keeps compatibility and supports the
more convenient collection usage, but the cost is some API bloat.
In my opinion, the slightly increased surface area from overloading is
worth the cost of keeping compatibility. Overloading is very common in Java
APIs, so there's no potential for confusion, and it has basically no
maintenance overhead. However, I know others already expressed opposition
to this, so if it's not agreeable, then I'm probably more inclined to keep
the current API. That said, it's not a strong preference. If the consensus
is to allow the breakage now, it doesn't seem like too big of a deal for
users to update their code. It might be early enough that most users
haven't finished (or perhaps haven't even started) migrating their code to
use the new consumer.
What do you think?
Thanks,
Jason
On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <py...@spootnik.org>
wrote:
>
> I updated the KIP accordingly.
>
> Cheers,
> - pyr
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
I updated the KIP accordingly.
Cheers,
- pyr
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
Hi Ismael,
Thanks for the review, I will act on these a bit later today.
- pyr
Ismael Juma writes:
> Thanks Pierre. Including the dev mailing list.
>
> A few comments:
>
> 1. It's worth mentioning that the KafkaConsumer has the
> @InterfaceStability.Unstable annotation.
> 2. It would be good to show the existing signatures of the methods being
> changed before we show the changed signatures.
> 3. The proposed changes section mentions an alternative. I think the
> alternative should be moved to the "Rejected Alternatives" section.
> 4. It would be good to explain why `Collection` was chosen specifically for
> the parameters (as opposed to `Iterable` for example).\
> 5. Finally, it would be good to explain why we decided to change the method
> parameters instead of the return types (or why we should not change the
> return types).
>
> Hopefully it should be straightforward to address these points.
>
> Thanks,
> Ismael
>
> On Tue, Jan 26, 2016 at 9:00 AM, Pierre-Yves Ritschard <py...@spootnik.org>
> wrote:
>
>>
>> KAFKA-3006 is under review, and would change some commonly used
>> signatures in the Kafka client library. The idea behind the proposal is
>> to provide a unified way of interacting with anything sequence like in
>> the client.
>>
>> If the change is accepted, these would be the signatures that change:
>>
>> void subscribe(Collection<String> topics);
>> void subscribe(Collection<String> topics, ConsumerRebalanceListener);
>> void assign(Collection<TopicPartition> partitions);
>> void pause(Collection<TopicPartition> partitions);
>> void resume(Collection<TopicPartition> partitions);
>> void seekToBeginning(Collection<TopicPartition>);
>> void seekToEnd(Collection<TopicPartition>);
>>
>>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Thanks Pierre. Including the dev mailing list.
A few comments:
1. It's worth mentioning that the KafkaConsumer has the
@InterfaceStability.Unstable annotation.
2. It would be good to show the existing signatures of the methods being
changed before we show the changed signatures.
3. The proposed changes section mentions an alternative. I think the
alternative should be moved to the "Rejected Alternatives" section.
4. It would be good to explain why `Collection` was chosen specifically for
the parameters (as opposed to `Iterable` for example).\
5. Finally, it would be good to explain why we decided to change the method
parameters instead of the return types (or why we should not change the
return types).
Hopefully it should be straightforward to address these points.
Thanks,
Ismael
On Tue, Jan 26, 2016 at 9:00 AM, Pierre-Yves Ritschard <py...@spootnik.org>
wrote:
>
> KAFKA-3006 is under review, and would change some commonly used
> signatures in the Kafka client library. The idea behind the proposal is
> to provide a unified way of interacting with anything sequence like in
> the client.
>
> If the change is accepted, these would be the signatures that change:
>
> void subscribe(Collection<String> topics);
> void subscribe(Collection<String> topics, ConsumerRebalanceListener);
> void assign(Collection<TopicPartition> partitions);
> void pause(Collection<TopicPartition> partitions);
> void resume(Collection<TopicPartition> partitions);
> void seekToBeginning(Collection<TopicPartition>);
> void seekToEnd(Collection<TopicPartition>);
>
>
Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.
Posted by Ismael Juma <is...@juma.me.uk>.
Thanks Pierre. Including the dev mailing list.
A few comments:
1. It's worth mentioning that the KafkaConsumer has the
@InterfaceStability.Unstable annotation.
2. It would be good to show the existing signatures of the methods being
changed before we show the changed signatures.
3. The proposed changes section mentions an alternative. I think the
alternative should be moved to the "Rejected Alternatives" section.
4. It would be good to explain why `Collection` was chosen specifically for
the parameters (as opposed to `Iterable` for example).\
5. Finally, it would be good to explain why we decided to change the method
parameters instead of the return types (or why we should not change the
return types).
Hopefully it should be straightforward to address these points.
Thanks,
Ismael
On Tue, Jan 26, 2016 at 9:00 AM, Pierre-Yves Ritschard <py...@spootnik.org>
wrote:
>
> KAFKA-3006 is under review, and would change some commonly used
> signatures in the Kafka client library. The idea behind the proposal is
> to provide a unified way of interacting with anything sequence like in
> the client.
>
> If the change is accepted, these would be the signatures that change:
>
> void subscribe(Collection<String> topics);
> void subscribe(Collection<String> topics, ConsumerRebalanceListener);
> void assign(Collection<TopicPartition> partitions);
> void pause(Collection<TopicPartition> partitions);
> void resume(Collection<TopicPartition> partitions);
> void seekToBeginning(Collection<TopicPartition>);
> void seekToEnd(Collection<TopicPartition>);
>
>