Yes, the consumer handles this error by rejoining the group. This is probably a case where the logging is a bit more verbose than it should be. I've tried to tune the logging a bit better for 0.10 so that some of these low-level details only come out at the DEBUG level (in particular for cases that we handle internally).
-Jason On Mon, Mar 14, 2016 at 6:50 PM, tao xiao <xiaotao...@gmail.com> wrote: > Thanks Jason. What does consumer 1 would do upon > receiving UNKNOWN_MEMBER_ID and does it rejoin the group eventually if it > keeps polling? > > On Tue, 15 Mar 2016 at 00:58 Jason Gustafson <ja...@confluent.io> wrote: > > > Hey Tao, > > > > This error indicates that a rebalance completed successfully before the > > consumer could rejoin. Basically it works like this: > > > > 1. Consumer 1 joins the group and is assigned member id A > > 2. Consumer 1's session timeout expires before successfully heartbeating. > > 3. The group is rebalanced without consumer 1. > > 4. Consumer 1 eventually sends its heartbeat using the old id A. > > 5. The coordinator rejects the heartbeat with UNKNOWN_MEMBER_ID. > > > > So most likely what has happened is that the consumer has taken longer > than > > the session timeout to handle a batch of records. In 0.10, we will have > an > > option max.poll.records to limit the amount of data returned from each > call > > to poll() so that you can better predict processing time. > > > > -Jason > > > > > > On Mon, Mar 14, 2016 at 7:04 AM, tao xiao <xiaotao...@gmail.com> wrote: > > > > > Hi team, > > > > > > I have about 10 consumers using the same consumer group connecting to > > > Kafka. Occasional I can see UNKNOWN_MEMBER_ID assigned to some of the > > > consumers. I want to under what situation this would happen? > > > > > > I use Kafka version 0.9.0.1 > > > > > >
