Thanks for the feedback! That's a good point about trying to prevent users from thinking they should use this API during normal processing and clarifying when/why you might need it -- regardless of the method name, we should explicitly call this out in the javadocs.
As for the method name, on reflection I agree that "rejoinGroup" does not seem to be appropriate. Of course that's what the consumer will actually be doing, but that's just an implementation detail -- the name should reflect what the API is doing, not how it does it (which can always change). How about "enforceRebalance"? This is stolen from the StreamThread method that does exactly this (by unsubscribing) so it seems to fit. I'll update the KIP with this unless anyone has another suggestion. Regarding the Consumer vs KafkaConsumer matter, I included the KafkaConsumer method because that's where all the javadocs redirect to in the Consumer interface. Also, FWIW I'm pretty sure KafkaConsumer is also part of the public API -- we would be adding a new method to both. On Fri, Feb 7, 2020 at 7:42 PM John Roesler <vvcep...@apache.org> wrote: > Hi all, > > Thanks for the well motivated KIP, Sophie. I had some alternatives in > mind, which > I won't even bother to relate because I feel like the motivation made a > compelling > argument for the API as proposed. > > One very minor point you might as well fix is that the API change is > targeted at > KafkaConsumer (the implementation), but should be targeted at > Consumer (the interface). > > I agree with your discomfort about the name. Adding a "rejoin" method > seems strange > since there's no "join" method. Instead the way you join the group the > first time is just > by calling "subscribe". But "resubscribe" seems too indirect from what > we're really trying > to do, which is to trigger a rebalance by sending a new JoinGroup request. > > Another angle is that we don't want the method to sound like something you > should > be calling in normal circumstances, or people will be "tricked" into > calling it unnecessarily. > > So, I think "rejoinGroup" is fine, although a person _might_ be forgiven > for thinking they > need to call it periodically or something. Did you consider > "triggerRebalance", which > sounds pretty advanced-ish, and accurately describes what happens when you > call it? > > All in all, the KIP sounds good to me, and I'm in favor. > > Thanks, > -John > > On Fri, Feb 7, 2020, at 21:22, Anna McDonald wrote: > > This situation was discussed at length after a recent talk I gave. This > KIP > > would be a great step towards increased availability and in facilitating > > lightweight rebalances. > > > > anna > > > > > > > > On Fri, Feb 7, 2020, 9:38 PM Sophie Blee-Goldman <sop...@confluent.io> > > wrote: > > > > > Hi all, > > > > > > In light of some recent and upcoming rebalancing and availability > > > improvements, it seems we have a need for explicitly triggering a > consumer > > > group rebalance. Therefore I'd like to propose adding a new > > > rejoinGroup()method > > > to the Consumer client (better method name suggestions are very > welcome). > > > > > > Please take a look at the KIP and let me know what you think! > > > > > > KIP document: > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-568%3A+Explicit+rebalance+triggering+on+the+Consumer > > > > > > JIRA: https://issues.apache.org/jira/browse/KAFKA-9525 > > > > > > Cheers, > > > Sophie > > > > > >
