+1 (non-binding) Thanks,
Mayuresh On Tue, Dec 4, 2018 at 6:58 AM Mike Freyberger <mike.freyber...@xandr.com> wrote: > +1 (non binding) > > On 12/4/18, 9:43 AM, "Patrick Williams" <patrick.willi...@storageos.com> > wrote: > > 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 > > > > > -- -Regards, Mayuresh R. Gharat (862) 250-7125
