----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/75363/#review227267 -----------------------------------------------------------
Ship it! Ship It! - Vyom Tiwari On Feb. 22, 2025, 8 a.m., gooch gooch wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/75363/ > ----------------------------------------------------------- > > (Updated Feb. 22, 2025, 8 a.m.) > > > Review request for ranger. > > > Repository: ranger > > > Description > ------- > > 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 > > ``` > org.apache.ranger.common.RangerRoleCache.RangerRoleCacheWrapper#getLatestRangerRoles. > > ``` > > 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. > > The way this patch solves the problem: > After acquiring the lock, a check is performed to determine whether the role > version number in the cache is already greater than or equal to the version > number retrieved from the database. If this condition evaluates to true, the > cached data can be directly returned. > > > Diffs > ----- > > security-admin/src/main/java/org/apache/ranger/common/RangerRoleCache.java > 247a48b46 > > > Diff: https://reviews.apache.org/r/75363/diff/4/ > > > Testing > ------- > > Tested locally. > > > Thanks, > > gooch gooch > >
