kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "M. Manna" <manme...@gmail.com>
Subject Re: [VOTE] KIP-369 Alternative Partitioner to Support "Always Round-Robin" Selection
Date Thu, 04 Apr 2019 23:18:32 GMT
Thanks Harsha.

As per your comments, I have counted 3 binding votes so far.

Thanks everyone for your comments and support. I’ll update the kip next
morning and do  the needful.

Regards,

On Thu, 4 Apr 2019 at 22:10, Harsha <kafka@harsha.io> wrote:

> Looks like the KIP is passed with 3 binding votes.  From Matthias, Bill
> Bejeck and myself you got 3 binding votes.
> You can do the full tally of the votes and send out a close of vote thread.
>
> Thanks,
> Harsha
>
> On Thu, Apr 4, 2019, at 12:24 PM, M. Manna wrote:
> > Hello,
> >
> > Trying to revive this thread again. Would anyone be interested in having
> > this KiP through
> >
> >
> > Thanks,
> >
> > On Fri, 25 Jan 2019 at 16:44, M. Manna <manmedia@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I am trying to revive this thread. I only got 1 binding vote so far.
> > >
> > > Please feel free to revisit and comment here.
> > >
> > > Thanks,
> > >
> > > On Thu, 25 Oct 2018 at 00:15, M. Manna <manmedia@gmail.com> wrote:
> > >
> > >> Hey IJ,
> > >>
> > >> Thanks for your interest in the KIP.
> > >>
> > >> My point was simply that the round-robin should happen even if the
> key is
> > >> not null. As for the importance of key in our case, we treat the key
> as
> > >> metadata. Each key is composed of certain info which are parsed by our
> > >> consumer thread. We will then determine whether it's an actionable
> message
> > >> (e.g. process it), or a loopback(ignore it). You could argue, "Why not
> > >> append this metadata with the record and parse it there?". But that
> means
> > >> the following:
> > >>
> > >> 1) I'm always passing null key to achieve this - I would like to pass
> > >> Null/Not-Null/Other key i.e. flexibility
> > >> 2) Suppose the message size is 99 KB and and max message bytes
> allowed is
> > >> 100K. Now prefixing metadata with message results into the actual
> message
> > >> being 101K. This will fail at producer level and cause a retry/log
> this in
> > >> our DB for future pickup.
> > >>
> > >> To avoid all these, we are simply proposing this new partitioner
> class.
> > >> but all Kafka new releases will still have DefaultPartitioner as
> default,
> > >> unless they change the prop file to use our new class.
> > >>
> > >> Regards,
> > >>
> > >> On Sun, 21 Oct 2018 at 04:05, Ismael Juma <ismael@juma.me.uk> wrote:
> > >>
> > >>> Thanks for the KIP. Can you please elaborate on the need for the key
> in
> > >>> this case? The KIP simply states that the key is needed for
> metadata, but
> > >>> doesn't give any more details.
> > >>>
> > >>> Ismael
> > >>>
> > >>> On Tue, Sep 4, 2018 at 3:39 AM M. Manna <manmedia@gmail.com>
wrote:
> > >>>
> > >>> > Hello,
> > >>> >
> > >>> > I have made necessary changes as per the original discussion
> thread,
> > >>> and
> > >>> > would like to put it for votes.
> > >>> >
> > >>> > Thank you very much for your suggestion and guidance so far.
> > >>> >
> > >>> > Regards,
> > >>> >
> > >>>
> > >>
> >
>

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