Delaying the SyncGroupRequest is not what I had in mind. What I was thinking was essentially a client-side stabilization window where the client does nothing other than participate in the group membership protocol and wait a bit for the group to stabilize.
During this window, several rounds of rebalance can take place, clients would participate in these rebalances (they'd get notified of the rebalance from the heartbeats they've been sending during this stabilization window), but they would effectively not run any ConsumerRebalanceListener.onPartitionsAssigned or process messages until the window has closed or rebalance finishes if the window ends during a rebalance. So something like: T0: client A is processing messages T1: new client B joins T2: client A gets notified and rejoins the group. T3: rebalance finishes with the group consisting of A and B. This is where the stabilization window begins for both A and B. Stabilization window duration is W. T4: new client C joins. T5: clients A and B get notified and they rejoin the group. T6: rebalance finishes with the group consisting of A, B, and C. T3+W: clients A, B, and C finally run their ConsumerRebalanceListener.onPartitionsAssigned and begin processing messages. If T3+W is during the middle of a rebalance, then we wait until that rebalance round finishes. Otherwise, we just run the ConsumerRebalanceListener.onPartitionsAssigned and begin processing messages. On Mon, Apr 3, 2017 at 11:40 AM, Becket Qin <becket....@gmail.com> wrote: > Hey Onur, > > Are you suggesting letting the consumers to hold back on sending > SyncGroupRequest on the first rebalance? I am not sure how exactly that > works. But it looks that having the group coordinator to control the > rebalance progress would be clearer and probably safer than letting the > group members to guess the state of a group. Can you elaborate a little bit > on your idea? > > Thanks, > > Jiangjie (Becket) Qin > > On Mon, Apr 3, 2017 at 8:16 AM, Onur Karaman <onurkaraman.apa...@gmail.com > > > wrote: > > > Hi Damian. > > > > After reading the discussion thread again, it still doesn't seem like the > > thread discussed the option I mentioned earlier. > > > > From what I had understood from the broker-side vs. client-side config > > debate was that the client-side config from the discussion would cause a > > wire format change, while the client-side config change that I had > > suggested would not. > > > > I just want to make sure we don't accidentally skip past it due to a > > potential misunderstanding. > > > > On Mon, Apr 3, 2017 at 8:10 AM, Bill Bejeck <bbej...@gmail.com> wrote: > > > > > +1 (non-binding) > > > > > > On Mon, Apr 3, 2017 at 9:53 AM, Mathieu Fenniak < > > > mathieu.fenn...@replicon.com> wrote: > > > > > > > +1 (non-binding) > > > > > > > > This will be very helpful for me, looking forward to it! :-) > > > > > > > > On Thu, Mar 30, 2017 at 4:46 AM, Damian Guy <damian....@gmail.com> > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > I'd like to start the voting thread on KIP-134: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > > > > > 134%3A+Delay+initial+consumer+group+rebalance > > > > > > > > > > Thanks, > > > > > Damian > > > > > > > > > > > > > > >
