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