lianetm commented on PR #17244: URL: https://github.com/apache/kafka/pull/17244#issuecomment-2377319827
Regarding: > I haven't had a chance to dig into the root cause as I'm curious what can be done at that layer so that the consumer doesn't have to be aware of it. My thoughts in case it helps. As I understand it, the root cause is a combination of: 1. the consumer keeps requesting metadata for a topic (invalid) while "needed" (until it unsubscribes) -> this is common for both consumers, because it considers it can "recover" from it https://github.com/apache/kafka/blob/7c429f3514dd50e98f42c74595c35b5f0b32b7d7/clients/src/main/java/org/apache/kafka/clients/Metadata.java#L643 (recover meaning no longer subscribed, so unsubscribed) 2. the legacy consumer does poll the network client in this test (no need to send leave because it's not in the group), but the async consumer does poll (background thread continuously polls the network client) So I think it makes sense to handle this at the unsubscribe level, where we understand why it's ok to ignore the exception (because it's actually the way to recover from it). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
