Status

Current state: Accepted

Discussion thread: https://lists.apache.org/thread.html/r7f1232b662cf46301a8b6cca1cfc29125203171f7b8188c2085b28e9%40%3Cdev.kafka.apache.org%3E

JIRA: Unable to render Jira issues macro, execution error.

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

 Like the jira:  Unable to render Jira issues macro, execution error.  ,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.

Public Interfaces

A public interface is any change to the following:

• update this old class

  • core/src/main/scala/kafka/security/authorizer/AclAuthorizer.scala

• add these new class

  • core/src/main/scala/kafka/security/authorizer/CachedAuthorizer.scala

  • core/src/test/scala/unit/kafka/security/authorizer/CachedAuthorizerTest.scala

Proposed Changes

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.

Rejected Alternatives

As mentioned in the Proposed changes, this is inefficient.