-
Bug
-
Resolution: Timed out
-
Low
-
None
-
2.1
-
None
-
Severity 3 - Minor
-
The DirectoryManagerGeneric.isUserNestedGroupMember iterates nested groups downwards from the target group, rather than upward from the starting user, which requires significantly more DAO operations (many of which are not currently cached in Confluence). It should instead iterate upward from the direct memberships of the user, and then the memberships of those groups. This will allow the isUserDirectGroupMember/isGroupDirectGroupMember calls to reuse the same cached data as the recursive calls do. This will also make the cached values much smaller, and less likely to become invalidated on a sync, since they will be the short list of groups a user or group is in, rather than the potentially vast list of groups or users that are in a group.
[CWD-2442] isUserNestedGroupMember iterates children, should iterate parents
| Workflow | Original: Simplified Crowd Development Workflow v2 - restricted [ 1509239 ] | New: JAC Bug Workflow v3 [ 3365750 ] |
| Symptom Severity | Original: Minor [ 14432 ] | New: Severity 3 - Minor [ 15832 ] |
| Resolution | New: Timed out [ 10 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
| Symptom Severity | New: Minor [ 14432 ] |
| Workflow | Original: Simplified Crowd Development Workflow v2 [ 1390978 ] | New: Simplified Crowd Development Workflow v2 - restricted [ 1509239 ] |
| Workflow | Original: Crowd Development Workflow v2 [ 292559 ] | New: Simplified Crowd Development Workflow v2 [ 1390978 ] |
Agreed. While crowd supports querying membership of LDAP without first synchronising LDAP to an internal directory, there's no point in rewriting the recursion. I still think it would be faster for all other directory types (or all synchronised directories) to query bottom up, especially where there are many group-group memberships of the target group.
Do you want me to rewrite this issue, or raise a new one for changing searchDirectGroupRelationships?
This is not a bug. Resolving nesting downwards from the group produces exactly the same result as resolving nesting upwards from the user.
The performance implication specific to Confluence arises because of the way caching is implemented at the DAO level. If you cache the direct subgroups of a group, this will take care of the performance issue. Caching a collection of subgroup references/names should not consume a large amount of memory.
I think in Crowd though, we should change:
List<Group> subGroups = searchDirectGroupRelationships(directoryId, QueryBuilder.queryFor(Group.class, EntityDescriptor.group()).childrenOf(EntityDescriptor.group()).withName(groupName).returningAtMost(EntityQuery.ALL_RESULTS));
To return List<String> to facilitate name caching.
Thoughts?
Raised CWD-2465 to cover improving support for name caching of memberships.
Leaving this as is, so you can decide whether to call findNestedGroupMembershipsOfUser inside isUserNestedGroupMember if/when the former is known to perform well.