Current state: Accepted
Discussion thread: https://lists.apache.org/thread.html/r93be167479a782d1a02144ad00f4d2f9bb97a805a45918b29131d714%40%3Cdev.kafka.apache.org%3E
KAFKA-9452Getting issue details...
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Like the jira: - KAFKA-5261Getting issue details... STATUS ,We met the same performance issue in our production environment,hence, we make a revision for the mechamisum of authorization, our revision have such optimizations
1、Build a cache for authorization, which can avoid recomputation of authorization result. The authorization result will fetch on the result catch if the same result has been computed rather than compute it again
2、Differ from the pr GitHub Pull Request #3756, when we build the result cache of the authorization, we take the resource into first consideration. In this way, the authorization is recomputed only when the authorization are change of specific resource. Compared to the the frequency of recomputation can be reduced obviously.
A public interface is any change to the following:
update this old class
add these new class
PR Available here: https://github.com/apache/kafka/pull/7661
the method named authorizeAction in
The purpose of this method named authorizeAction in AclAuthorizer.scala is to calculate the AuthorizationResult under the current conditions.This method checks a lot of items and needs to traverse a lot of data: denyAcls / allowAcls / isSuperUser
Same calculations will only cause frequent gc and cpu rises,so we don't need to do the same calculations under the same conditions.
This optimization is to solve this problem. We cache each condition and result into the authorizerCache. The next time querying , we first get the authorizerCache. If there is, we can get the results. If not, we can use authorizeAction to calculate and add to authorizerCache
Compatibility, Deprecation, and Migration Plan
No impact or migration plan required as this proposal is only adding new methods and not changing any current behaviour.
As mentioned in the Proposed changes, this is inefficient.