Hi Jun, The patches that I've got currently wait for the elections to complete before returning the response. Is that the semantic you wanted?
Cheers, Tom On 7 September 2017 at 22:14, Jun Rao <j...@confluent.io> wrote: > 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 <cmcc...@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 <cmcc...@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 > > >
