If there is no additional feedback on this KIP I'll start a vote soon.
Thanks.
--Vahid
From: "Vahid S Hashemian"
To: dev@kafka.apache.org
Date: 07/18/2018 04:47 PM
Subject: Re: [DISCUSS] KIP-341: Update Sticky Assignor's User Data
Protocol
The KIP is updated
The KIP is updated to follow the suggestion of using consumer group
generation.
--Vahid
From: "Vahid S Hashemian"
To: dev@kafka.apache.org
Date: 07/17/2018 02:32 PM
Subject: Re: [DISCUSS] KIP-341: Update Sticky Assignor's User Data
Protocol
Hi Jaso
PM
Subject: Re: [DISCUSS] KIP-341: Update Sticky Assignor's User Data
Protocol
Hey Vahid,
I'm with Mike that it seems simpler to just use the consumer group
generation. Even if you can figure out how to reason about the local
generation, it still seems confusing to have something called &
eyberger
>
> To: "dev@kafka.apache.org"
>
> Date: 07/13/2018 08:42 PM
>
> Subject:Re: [DISCUSS] KIP-341: Update Sticky Assignor's User Data
>
> Protocol
>
>
>
>
>
>
>
> This is great!
>
>
>
> For the clie
to introducing another
field (e.g. timestamp).
Regards.
--Vahid
From: Mike Freyberger
To: "dev@kafka.apache.org"
Date: 07/13/2018 08:42 PM
Subject: Re: [DISCUSS] KIP-341: Update Sticky Assignor's User Data
Protocol
This is great!
For the client side implementatio
This is great!
For the client side implementation, I think it’s still possible for there to be
a duplication. I’ll try to walk through the example here.
Let’s says there are 2 consumers, 1 topic with 2 partitions.
After the initial rebalance, generation 0:
Consumer A has partition 0
Consumer
Hi all,
I create a short KIP to address an issue in Sticky Assignor assignment
logic:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-341%3A+Update+Sticky+Assignor%27s+User+Data+Protocol
Please take a look and share your feedback / comments.
In particular, there is a Generation Marker
