[jira] [Created] (KAFKA-13889) Broker can't handle ACCESS_CONTROL_ENTRY_RECORD quickly followed by REMOVE_ACCESS_CONTROL_ENTRY_RECORD for same ACL

["Andrew Grant (Jira)" <ji...@apache.org>]

Andrew Grant created KAFKA-13889:
------------------------------------

             Summary: Broker can't handle ACCESS_CONTROL_ENTRY_RECORD quickly followed by REMOVE_ACCESS_CONTROL_ENTRY_RECORD for same ACL
                 Key: KAFKA-13889
                 URL: https://issues.apache.org/jira/browse/KAFKA-13889
             Project: Kafka
          Issue Type: Bug
            Reporter: Andrew Grant


In https://github.com/apache/kafka/blob/trunk/metadata/src/main/java/org/apache/kafka/image/AclsDelta.java#L64 we store the pending deletion in the changes map. This could override a creation that might have just happened. This is an issue because in BrokerMetadataPublisher this results in us making a removeAcl call which finally results in [https://github.com/apache/kafka/blob/trunk/metadata/src/main/java/org/apache/kafka/metadata/authorizer/StandardAuthorizerData.java#L203] being executed and this code throws an exception if the ACL isnt in the Map yet. If the ACCESS_CONTROL_ENTRY_RECORD event never got processed by BrokerMetadataPublisher then the ACL wont be in the Map yet.

My feeling is we might want to make removeAcl idempotent in that it returns success if the ACL doesn't exist: no matter how many times removeAcl is called it returns success if the ACL is deleted. Maybe we’d just log a warning or something?

 

Note, I dont think the AclControlManager has this issue because it doesn't batch the events like AclsDelta does. However, we still do throw a RuntimeException here [https://github.com/apache/kafka/blob/trunk/metadata/src/main/java/org/apache/kafka/controller/AclControlManager.java#L197] - maybe we should still follow the same logic (if we make the fix suggested above) and just log a warning if the ACL doesnt exist in the Map?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)