You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "David Jacot (Jira)" <ji...@apache.org> on 2021/06/04 15:39:00 UTC
[jira] [Commented] (KAFKA-12896) Group rebalance loop caused by
repeated group leader JoinGroups
[ https://issues.apache.org/jira/browse/KAFKA-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17357446#comment-17357446 ]
David Jacot commented on KAFKA-12896:
-------------------------------------
I have found a bug while investigating this one: https://issues.apache.org/jira/browse/KAFKA-12898. It does not explain why the leader tries to rejoin the group but it does explain why the group coordinator rebalances the group.
> Group rebalance loop caused by repeated group leader JoinGroups
> ---------------------------------------------------------------
>
> Key: KAFKA-12896
> URL: https://issues.apache.org/jira/browse/KAFKA-12896
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 2.6.0
> Reporter: Lucas Bradstreet
> Assignee: David Jacot
> Priority: Major
>
> We encountered a strange case of a rebalance loop with the "cooperative-sticky" assignor. The logs show the following for several hours:
>
> {{Apr 7, 2021 @ 03:58:36.040 [GroupCoordinator 7]: Stabilized group mygroup generation 19830137 (__consumer_offsets-7)}}
> {{Apr 7, 2021 @ 03:58:35.992 [GroupCoordinator 7]: Preparing to rebalance group mygroup in state PreparingRebalance with old generation 19830136 (__consumer_offsets-7) (reason: Updating metadata for member mygroup-1-7ad27e07-3784-4588-97e1-d796a74d4ecc during CompletingRebalance)}}
> {{Apr 7, 2021 @ 03:58:35.988 [GroupCoordinator 7]: Stabilized group mygroup generation 19830136 (__consumer_offsets-7)}}
> {{Apr 7, 2021 @ 03:58:35.972 [GroupCoordinator 7]: Preparing to rebalance group mygroup in state PreparingRebalance with old generation 19830135 (__consumer_offsets-7) (reason: Updating metadata for member mygroup during CompletingRebalance)}}
> {{Apr 7, 2021 @ 03:58:35.965 [GroupCoordinator 7]: Stabilized group mygroup generation 19830135 (__consumer_offsets-7)}}
> {{Apr 7, 2021 @ 03:58:35.953 [GroupCoordinator 7]: Preparing to rebalance group mygroup in state PreparingRebalance with old generation 19830134 (__consumer_offsets-7) (reason: Updating metadata for member mygroup-7ad27e07-3784-4588-97e1-d796a74d4ecc during CompletingRebalance)}}
> {{Apr 7, 2021 @ 03:58:35.941 [GroupCoordinator 7]: Stabilized group mygroup generation 19830134 (__consumer_offsets-7)}}
> {{Apr 7, 2021 @ 03:58:35.926 [GroupCoordinator 7]: Preparing to rebalance group mygroup in state PreparingRebalance with old generation 19830133 (__consumer_offsets-7) (reason: Updating metadata for member mygroup during CompletingRebalance)}}
> Every single time, it was the same member that triggered the JoinGroup and it was always the leader of the group.{{}}
> The leader has the privilege of being able to trigger a rebalance by sending `JoinGroup` even if its subscription metadata has not changed. But why would it do so?
> It is possible that this is due to the same issue or a similar bug to https://issues.apache.org/jira/browse/KAFKA-12890.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)