Hi Guozhang, I think the motivation for the new API makes sense. I've wanted something like this in the past. That said, do you think there is a substantial benefit from deprecating the old API? I can still see it being convenient in some cases and it's no real cost to maintain.
Also, just a minor detail. If the partition has no committed offset, will it be present in the map with a null value? -Jason On Tue, Sep 10, 2019 at 6:09 AM Mickael Maison <mickael.mai...@gmail.com> wrote: > +1 (non-binding), thanks Guozhang > > On Tue, Sep 10, 2019 at 1:14 AM Boyang Chen <reluctanthero...@gmail.com> > wrote: > > > > Hey Guozhang, > > > > LGTM, +1 (non-binding) > > > > On Mon, Sep 9, 2019 at 5:07 PM Guozhang Wang <wangg...@gmail.com> wrote: > > > > > Hello folks, > > > > > > I've created a new KIP allowing consumer.committed to take a set of > > > partitions instead of just one partition to allow batching effects of > such > > > requests (the protocol already allows us to send multiple partitions > in one > > > round-trip): > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-520%3A+Add+overloaded+Consumer%23committed+for+batching+partitions > > > > > > Since it is a pretty straight-forward KIP, I'm starting the VOTE for > this > > > KIP directly. If there are any suggestions about this proposal, please > feel > > > free to share them in this thread. Thank you! > > > > > > > > > -- Guozhang > > > >
