gooch created RANGER-5148:
-----------------------------
Summary: 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
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)
