hudeqi commented on PR #13913: URL: https://github.com/apache/kafka/pull/13913#issuecomment-1635200263
Especially thanks for your separate reply! @C0urante I have tracked it in the [Jira ticket](https://issues.apache.org/jira/browse/KAFKA-15172). Going back to this PR, although it is named incremental ACL synchronization, it does not change the existing behavior. The reason is: `knownTopicAclBindings` saves all the ACL that `MirrorSourceConnector` has sensed for the synchronization topics of the source cluster and has been synchronized to the target cluster. When the initial startup, all relevant ACL will be synchronized, and then as long as the source cluster ACL changes, it will be synchronized to the target cluster again as a new ACL (so it caches not the view of the target cluster's ACLs, but the view of the source cluster's ACLs), as for you mentioned "The current behavior is responsible not only for creating initial ACL bindings, but also for continuously re-applying them if they are changed." In fact, the logic has not changed, because the `AclBinding` class implements `equals` layer by layer, the resynchronization of the changed `AclBinding` should not be missed. In addition, the "affect the accumulation of the request queue of the target cluster and further affect the processing delay of other type requests" I mentioned is not groundless. It is a serious problem found in production environment. It can be seen that full synchronization and incremental synchronization are important for target cluster producer latency impact:   -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
