[ https://issues.apache.org/jira/browse/PHOENIX-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kiran Kumar Maturi updated PHOENIX-5269: ---------------------------------------- Attachment: PHOENIX-5269-4.14-HBase-1.4.patch > PhoenixAccessController should use AccessChecker instead of > AccessControlClient for permission checks > ----------------------------------------------------------------------------------------------------- > > Key: PHOENIX-5269 > URL: https://issues.apache.org/jira/browse/PHOENIX-5269 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.14.1, 4.14.2 > Reporter: Andrew Purtell > Assignee: Kiran Kumar Maturi > Priority: Critical > Attachments: PHOENIX-5269-4.14-HBase-1.4.patch > > > PhoenixAccessController should use AccessChecker instead of > AccessControlClient for permission checks. > In HBase, every RegionServer's AccessController maintains a local cache of > permissions. At startup time they are initialized from the ACL table. > Whenever the ACL table is changed (via grant or revoke) the AC on the ACL > table "broadcasts" the change via zookeeper, which updates the cache. This is > performed and managed by TableAuthManager but is exposed as API by > AccessChecker. AccessChecker is the result of a refactor that was committed > as far back as branch-1.4 I believe. > Phoenix implements its own access controller and is using the client API > AccessControlClient instead. AccessControlClient does not cache nor use the > ZK-based cache update mechanism, because it is designed for client side use. > The use of AccessControlClient instead of AccessChecker is not scalable. > Every permissions check will trigger a remote RPC to the ACL table, which is > generally going to be a single region hosted on a single RegionServer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)