You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Ramachandran Krishnan (Jira)" <ji...@apache.org> on 2026/05/26 10:14:00 UTC
[jira] [Created] (RANGER-5614) Role creation/updation takes more time when there are more users,groups,roles
Ramachandran Krishnan created RANGER-5614:
---------------------------------------------
Summary: Role creation/updation takes more time when there are more users,groups,roles
Key: RANGER-5614
URL: https://issues.apache.org/jira/browse/RANGER-5614
Project: Ranger
Issue Type: Task
Components: Ranger
Affects Versions: 2.8.0
Reporter: Ramachandran Krishnan
Assignee: Ramachandran Krishnan
Fix For: 3.0.0
In high-scale enterprise environments deploying Apache Ranger, administrative tasks often involve creating or syncing massive hierarchical structures consisting of thousands of roles, users, and groups. In the unoptimized legacy runtime path, when a new role assignment or update was processed via the API, the business logic engine executed individual, standalone queries against the relational store for every single principal listed in the membership array.
This design resulted in severe performance degradation due to the {*}N+1 query execution pattern{*}. Specifically, for a role containing $U$ users, $G$ groups, and $R$ referenced sub-roles, the relational engine was forced to execute distinct lookup operations followed by iterative insertion calls for each member. This architecture exhausted open database thread pools, caused elevated query latencies, and induced transactional locks during large automated sync updates.
By leveraging configuration flags like ranger.admin.role.create.batch.enabled and refactoring data access paths inside RoleRefUpdater.java, lookup loops were replaced with collection-level map pre-fetching. Iterative single-record creations were updated to utilize underlying database batch extensions, drastically minimizing JDBC network overhead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)