[
https://issues.apache.org/jira/browse/KAFKA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boyang Chen reassigned KAFKA-10674:
-----------------------------------
Assignee: Boyang Chen
> 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
> Assignee: 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)
