Hi Spico, Yes your theory is correct. The sloppy consumer waited in onPartitionRevoked until session timed out and another round of group rebalance was triggered which resulted in Consumer B taking all partitions. After waking up from sleep group rebalance was triggered again
On Wed, 11 May 2016 at 06:44 Spico Florin <spicoflo...@gmail.com> wrote: > Hi! > Here is a great article about the consumer API: > > http://www.confluent.io/blog/tutorial-getting-started-with-the-new-apache-kafka-0.9-consumer-client > . > In my opinion, the consumer will not be able to send the heartbeat to the > group coordinator (due to the fact that poll calls on onPartitionRevoked > and onPratitionAssigned in the same thread) in the expected session > timeout. Therefore a new rebalance will be issued. I suppose that consumer > that B will take all the partitions but, it will be affected all the time > by the sloppy consumer A that after each poll joins the group and triggers > rebalance. > You could do a test with a Thread.sleep with a time that exceeds the > session timeout in the onPartitionRevoked and see if the above described > behavior is fine. For both of theconsumers put the > ConsumerRebalanceListener. > I look forward for your results. > Florin > > On Tue, May 10, 2016 at 9:51 PM, tao xiao <xiaotao...@gmail.com> wrote: > > > Hi team, > > > > I want to know what would happen if the consumer group rebalance takes > long > > time like longer than the session timeout? > > > > For example I have two consumers A and B using the same group id. For > some > > reasons during rebalance consumer A takes long time to finish > > onPartitionsRevoked what would happen to B? does B take over all the > topics > > and continue consumption? And what would happen to both A and B after A > > finishes the long processing? > > >
