Hi Boyang,

Thanks for the quick response.
We are on version 2.2.0.

We are using the following properties on KStreams/consumer:
session.timeout.ms=15000
heartbeat.interval.ms=3000

I was wondering if a member might leak if it satisfies “shouldKeepAlive” 
condition in "onExpireHeartbeat" and the consumer restarts or goes down right 
after that, before next heartbeat is sent.

Thanks
Aravind


> On Jul 10, 2019, at 10:40 PM, Boyang Chen <reluctanthero...@gmail.com> wrote:
> 
> Hey Aravind,
> 
> If your client/broker just upgraded to 2.3, Jason has filed a blocker for
> 2.3: https://issues.apache.org/jira/browse/KAFKA-8653
> 
> and a fix is on its way: https://github.com/apache/kafka/pull/7072/files
> 
> Let me know if you are actually on a different version.
> 
> Boyang
> 
> On Wed, Jul 10, 2019 at 7:43 PM Aravind Dongara <adong...@yahoo.com.invalid>
> wrote:
> 
>> Our kafka streams application is stuck and continuously emits
>> "(Re-)joining group” log message every 5 minutes without making any
>> progress.
>> 
>> Kafka-consumer-groups cmd line tool with “—members” option shows lots of
>> stale members, in addition to expected member-ids shown on log msgs on
>> kafka-streams app and broker logs that were failing to join).
>> For some reason these old members didn’t get evicted from members list.
>> Looks like this is preventing the GroupCordinator from reaching
>> “CompletingRebalance” state.
>> 
>> Restart of Kafka streams app didn’t help either, it just replaced the
>> newer member-ids; but the old stale member-ids are still present in the
>> members-list.
>> 
>> Is there any way to resolve this without restarting the broker hosting the
>> GroupCoordinator for this group.
>> 
>> Thanks
>> Aravind

Reply via email to