Pls take me off this VOTE list
Best,
Patrick Williams
Sales Manager, UK & Ireland, Nordics & Israel
StorageOS
+44 (0)7549 676279
patrick.willi...@storageos.com
20 Midtown
20 Proctor Street
Holborn
London WC1V 6NX
Twitter: @patch37
LinkedIn: linkedin.com/in/patrickwilliams4
<http://linkedin.com/in/patrickwilliams4>
https://slack.storageos.com/
On 03/12/2018, 17:34, "Guozhang Wang" <wangg...@gmail.com> wrote:
Hello Boyang,
I've browsed through the new wiki and there are still a couple of minor
things to notice:
1. RemoveMemberFromGroupOptions seems not defined anywhere.
2. LeaveGroupRequest added a list of group instance id, but still keep the
member id as a singleton; is that intentional? I think to make the protocol
consistent both member id and instance ids could be plural.
3. About the *kafka-remove-member-from-group.sh *tool, I'm wondering if we
can defer adding this while just add the corresponding calls of the
LeaveGroupRequest inside Streams until we have used it in production and
hence have a better understanding on how flexible or extensible if we want
to add any cmd tools. The rationale is that if we do not necessarily need
it now, we can always add it later with a more think-through API design,
but if we add the tool in a rush, we may need to extend or modify it soon
after we realize its limits in operations.
Otherwise, I'm +1 on the proposal.
Guozhang
On Mon, Dec 3, 2018 at 9:14 AM Boyang Chen <bche...@outlook.com> wrote:
> Hey community friends,
>
> after another month of polishing, KIP-345<
>
https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances>
> design is ready for vote. Feel free to add your comment on the discussion
> thread or here.
>
> Thanks for your time!
>
> Boyang
> ________________________________
> From: Boyang Chen <bche...@outlook.com>
> Sent: Friday, November 9, 2018 6:35 AM
> To: dev@kafka.apache.org
> Subject: [VOTE] KIP-345: Introduce static membership protocol to reduce
> consumer rebalances
>
> Hey all,
>
>
> thanks so much for all the inputs on KIP-345 so far. The original proposal
> has enhanced a lot with your help. To make sure the implementation go
> smoothly without back and forth, I would like to start a vote on the final
> design agreement now:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-<
>
https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances
> >
>
> 345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances<
>
https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances
> >
>
> KIP-345: Introduce static membership protocol to reduce ...<
>
https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances
> >
> cwiki.apache.org
> For stateful applications, one of the biggest performance bottleneck is
> the state shuffling. In Kafka consumer, there is a concept called
> "rebalance" which means that for given M partitions and N consumers in one
> consumer group, Kafka will try to balance the load between consumers and
> ideally have ...
>
>
> Let me know if you have any questions.
>
>
> Best,
>
> Boyang
>
>
--
-- Guozhang
