[
https://issues.apache.org/jira/browse/RANGER-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhan Neethiraj resolved RANGER-5148.
--------------------------------------
Fix Version/s: 3.0.0
2.8.0
Resolution: Fixed
master branch:
[https://github.com/apache/ranger/commit/6d6bce47ff30a602256a8b97ebeafcfc5cce0a33]
ranger-2.8 branch:
https://github.com/apache/ranger/commit/397920ab6b253a348aa007e9b1d3c25f556bb022
> Redundant Role Cache Modification Triggers Caused by Role Version Changes in
> Scenarios with a Large Number of Plugin Clients
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: RANGER-5148
> URL: https://issues.apache.org/jira/browse/RANGER-5148
> Project: Ranger
> Issue Type: Improvement
> Components: admin
> Affects Versions: 3.0.0
> Reporter: gooch
> Priority: Critical
> Fix For: 3.0.0, 2.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This issue will occur when the number of Ranger plugin clients is
> sufficiently large. When the server performs an update operation on roles,
> which in turn causes the role version numbers in the database to be updated,
> multiple clients will concurrently obtain the latest information of all
> roles. During this process, the update of the cached roles in the Ranger
> Admin Server is triggered multiple times. In a concurrent scenario, this
> operation will generate a large number of unnecessary table-scanning updates.
> The relevant code is located at
> {code:java}
> org.apache.ranger.common.RangerRoleCache.RangerRoleCacheWrapper#getLatestRangerRoles.
> {code}
>
> The problem lies in the fact that after lock.tryLock, the thread that
> acquires the lock will definitely call the roleDBStore.getRoles method once.
> In a concurrent scenario, the previous threads have already triggered the
> update.
>
> Specifically, I only made one modification to the role, and the role version
> number increased by one. At this time, one thread holds the lock and is
> performing a table-scanning update, while there are 10 new threads waiting to
> compete for the lock. Subsequently, after each of these 10 threads acquires
> the lock, they will update the cache again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
