Hi there, Have you upgraded to 0.9.0.1? There were a couple bugs that may cause what you're seeing. After restarting, the maximum time to rejoin should be bounded by the session timeout (which defaults to 30 seconds). If it takes longer, you may have found a bug and we'd appreciate hearing the details.
Generally, unknown memberId is a recoverable error. It indicates that the consumer has fallen out of the group, so we simply rejoin. If you are seeing this, it likely means that the consumer has polled an unusually large batch of records which has taken longer to process than the session timeout. It could also be the case that the downstream system has suddenly slowed, but in that case, lag is unavoidable. In 0.10 (which is in the process of being released right now), we've introduced a configuration option "max.poll.records" which lets you tune the amount of data handled on each poll() iteration. With 0.9, the best option is probably just to increase the session timeout. -Jason On Wed, Mar 30, 2016 at 1:59 AM, chao zhang <[email protected]> wrote: > This question is about UNKNOWN_MEMBER_ID issue > > In fact , we meet the block issue . But we don't have solution to resolve > this problem .. > > For example : > > we have one job running on production environment, and consume data . But > suddenly , the consumer can not consume message (maybe heartbeat or session > timeout). After consumer restart to rejoin group , it cannot join consumer > group and keep A lot of LAGs. because of UNKNOWN_MEMBER_ID > > Because it is production , we can not change group name and re-consume > data, we need to use this group name : > > how can we continue to consume this message with same consumer group ?? > > where is Member id store (in zookeeper or Kafka)?? > > Do we have any solution to reset it in the KAFKA server side .For example , > remove member id and rejoin it ?? > > > -- > > Regards, > Zhang Chao >
