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 wrote:
> +users
>
> On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson
> wrote:
>
> > Hey Ismael,
> >
> > Thanks for bringing this up again. Just a quick
+users
On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson 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 proble
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 d
Coming back to this, see below.
On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson 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 shoul
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 situat
Hi Becket,
On Wed, Jan 27, 2016 at 10:51 PM, Becket Qin 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.toArr
>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
Hi Pierre and Jason,
A comment below.
On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson 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
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 pre
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 b
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 guess
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 go
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 c
13 matches
Mail list logo
