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)