kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mayuresh Gharat <gharatmayures...@gmail.com>
Subject Re: [VOTE] KIP-345: Introduce static membership protocol to reduce consumer rebalances
Date Thu, 06 Dec 2018 02:53:47 GMT
+1 (non-binding)

Thanks,

Mayuresh

On Tue, Dec 4, 2018 at 6:58 AM Mike Freyberger <mike.freyberger@xandr.com>
wrote:

> +1 (non binding)
>
> ´╗┐On 12/4/18, 9:43 AM, "Patrick Williams" <patrick.williams@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.williams@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" <wangguoz@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 <bchen11@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 <bchen11@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message