[
https://issues.apache.org/jira/browse/FC-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn McKinney closed FC-307.
-----------------------------
Resolution: Fixed
> Performance problem with roles many members
> --------------------------------------------
>
> Key: FC-307
> URL: https://issues.apache.org/jira/browse/FC-307
> Project: FORTRESS
> Issue Type: Improvement
> Affects Versions: 2.0.7
> Reporter: Shawn McKinney
> Assignee: Shawn McKinney
> Priority: Major
> Fix For: 2.0.8
>
>
> This issue brings performance improvements to situations where the
> role.occupants is enabled on role entries. The problem, is groups with many
> members can be costly to update and even read. Insertions are slow because
> large groups are expensive to process in LDAP. (There are mitigating and
> aggravating factors to consider on the server side that are beyond the scope
> of this discussion)
> We can also set 'role.occupants' flag to false, as already mentioned. This
> sidesteps this issue by not storing member information on the Role entry
> rather storing on the User entry only.
> To be clear, Fortress always store's the user's role membership on the user
> entry. The role.occupant flag controls the behavior of also storing the
> reverse, i.e. user membership on the role entry. There are pros/cons of each
> approach, and has to do with from what perspective the query is from. For
> example, given a user, return their roles will be more efficient by storing
> the membership on the user. Given a role, return the users will be more
> efficient storing the membership on the role.
> In any case, performing 'Reads' on very large groups is slow, because pulling
> those entries back may contain 1000's even hundreds of thousand of members.
> Think University group of 'student' or 'alumni' or a Bank's 'customer' role.
> This requires pulling back a bunch of data across, which is very expensive to
> do, even in LDAP. So, what we're trying to do here, is only pull back the
> role's members when absolutely necessary, iff the role.occupant is enabled.
> This issue addresses this by adding a method to the RoleP and RoleDAO classes
> called readConstraints. It only pulls back the constraints and parents on
> the entry and not its members or properties.
> This method replaces the role validation, constraint and hierarchical
> processing that occurs in the AdminMgrImpl class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
