kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Rao <...@confluent.io>
Subject Re: [DISCUSS] KIP-183 - Change PreferredReplicaLeaderElectionCommand to use AdminClient
Date Thu, 07 Sep 2017 21:14:54 GMT
Hi, Tom,

It seems that it's useful to know whether the leader is balanced for each
partition in ElectPreferredLeadersResult, instead of just being attempted?

Thanks,

Jun

On Wed, Sep 6, 2017 at 4:03 PM, Colin McCabe <cmccabe@apache.org> wrote:

> On Wed, Sep 6, 2017, at 01:18, Tom Bentley wrote:
> > Hi Colin,
> >
> > Thanks for taking the time to respond.
> >
> > On 5 September 2017 at 22:22, Colin McCabe <cmccabe@apache.org> wrote:
> >
> > > ...
> > > Why does there need to be a map at all in the API?
> >
> >
> > From a purely technical PoV there doesn't, but doing something else would
> > make the API inconsistent with other similar AdminClient *Results
> > classes,
> > which all expose a Map directly.
> >
> >
> > > Why not just have
> > > something like this:
> > >
> >
> > I agree this would be a better solution. I will update the KIP and ask
> > people to vote again. (Is that the right process?)
> >
> > It might be worth bearing this in mind for future AdminClient APIs:
> > Exposing a Map directly means you can't retrofit handling a null argument
> > to mean "all the things", whereas wrapping the map would allow that.
>
> That's a good point.
>
> I guess the important thing to keep in mind is that if you return a map
> from a results class, it has to be instantiated eagerly.  It has to be
> something you know before any RPCs are made, async actions are
> performed, etc.
>
> best,
> Colin
>
> >
> > Thanks again,
> >
> > Tom
>

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