[ https://issues.apache.org/jira/browse/KAFKA-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998700#comment-16998700 ]
Matthias J. Sax commented on KAFKA-9146: ---------------------------------------- If you use static group membership ([https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances]) you usually configure a long `session.timeout.ms` configuration – if you want to stop/remove an instance from the group (ie, scale-in your application), a rebalance would only happen after `session.timeout.ms` passed – hence the assigned partitions of the removed instance would be unprocessed for a long period of time. The idea of this ticket is, to allow user to trigger a rebalance manually to avoid the long wait until session timeout passed. `KafkaAdminClient` offers a method `removeMembersFromConsumerGroup` to do this. The ides of this ticket is, to extend command line tools to support this functionality. Ie, we need need command line flags, and extend the tools to call the method. Does this help? Frankly, I am not sure what bullet point (2) in the ticket description about dynamic membership means? I guess [~bchen225242] can give more context. > Add option to force delete members in stream reset tool > ------------------------------------------------------- > > Key: KAFKA-9146 > URL: https://issues.apache.org/jira/browse/KAFKA-9146 > Project: Kafka > Issue Type: Improvement > Components: consumer, streams > Reporter: Boyang Chen > Assignee: feyman > Priority: Major > Labels: newbie > > Sometimes people want to reset the stream application sooner, but blocked by > the left-over members inside group coordinator, which only expire after > session timeout. When user configures a really long session timeout, it could > prevent the group from clearing. We should consider adding the support to > cleanup members by forcing them to leave the group. To do that, > # If the stream application is already on static membership, we could call > directly from adminClient.removeMembersFromGroup > # If the application is on dynamic membership, we should modify > adminClient.removeMembersFromGroup interface to allow deletion based on > member.id. -- This message was sent by Atlassian Jira (v8.3.4#803005)