[
https://issues.apache.org/jira/browse/RANGER-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17927820#comment-17927820
]
gooch commented on RANGER-5148:
-------------------------------
https://reviews.apache.org/r/75363/
> 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
> Time Spent: 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)
