lianetm commented on PR #15961: URL: https://github.com/apache/kafka/pull/15961#issuecomment-2148155631
Hey all, I still have concerns with this approach of a manager just to propagate the metadata errors. Not only that it still feels a bit like an overkill, but I'm worried it brings a fundamental timing difference with the legacy consumer. For both consumers, metadata errors are identified (saved to be propagated) on the NetworkClient when a metadata response is received ([here](https://github.com/apache/kafka/blob/55d38efcc5505a5a1bddb08ba05f4d923f8050f9/clients/src/main/java/org/apache/kafka/clients/NetworkClient.java#L942)). Then: - the legacy code throws metadata errors on the same poll iteration that discovered the error (detect error [here](https://github.com/apache/kafka/blob/55d38efcc5505a5a1bddb08ba05f4d923f8050f9/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkClient.java#L276-L284), throw it right after in the same poll ([here](https://github.com/apache/kafka/blob/55d38efcc5505a5a1bddb08ba05f4d923f8050f9/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkClient.java#L315))) - new code (with the current PR approach), would throw the metadata error on the next poll after the one that detected it (just because the ConsumerNetworkThread polls the managers before polling the network client, see [here](https://github.com/apache/kafka/blob/55d38efcc5505a5a1bddb08ba05f4d923f8050f9/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkThread.java#L144-L147)). Is there a concern with the alternative simple approach [suggested above](https://github.com/apache/kafka/pull/15961#issuecomment-2135478481)? Feels simpler and keeps to the semantics of the legacy client, ensuring that the same network layer poll that detects a metadata error will propagate it. Thoughts? -- 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
