[ https://issues.apache.org/jira/browse/KAFKA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyang Chen updated KAFKA-10674: -------------------------------- Parent: KAFKA-9705 Issue Type: Sub-task (was: Improvement) > Brokers should know the active controller ApiVersion after enabling KIP-590 > forwarding > -------------------------------------------------------------------------------------- > > Key: KAFKA-10674 > URL: https://issues.apache.org/jira/browse/KAFKA-10674 > Project: Kafka > Issue Type: Sub-task > Components: clients, core > Reporter: Boyang Chen > Priority: Major > > Admin clients send ApiVersions to the broker upon the first connection > establishes. The tricky thing after forwarding is enabled is that for > forwardable APIs, admin client needs to know a commonly-agreed range of > ApiVersions among handling broker, active controller and itself. > Right now the inter-broker APIs are guaranteed by IBP constraints, but not > for forwardable APIs. A compromised solution would be to put all forwardable > APIs under IBP, which is brittle and hard to maintain consistency. > Instead, any broker connecting to the active controller should send an > ApiVersion request from beginning, so it is easy to compute that information > and send back to the admin clients upon ApiVersion request from admin. Any > rolling of the active controller will trigger reconnection between broker and > controller, which guarantees a refreshed ApiVersions between the two. This > approach avoids the tight bond with IBP and broker could just close the > connection between admin client to trigger retry logic and refreshing of the > ApiVersions. Since this failure should be rare, two round-trips and timeout > delays are well compensated by the less engineering work. -- This message was sent by Atlassian Jira (v8.3.4#803005)