kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Sophie Blee-Goldman (Jira)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-12896) Group rebalance loop caused by repeated group leader JoinGroups
Date Thu, 15 Jul 2021 07:34:00 GMT

    [ https://issues.apache.org/jira/browse/KAFKA-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17381120#comment-17381120
] 

A. Sophie Blee-Goldman commented on KAFKA-12896:
------------------------------------------------

Yep, that should do it

> 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: Blocker
>             Fix For: 3.0.0
>
>
> 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)

Mime
View raw message