[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640344#comment-14640344
]
angela edited comment on OAK-3003 at 7/28/15 12:04 PM:
-------------------------------------------------------
continued working on this and found more missing test:
- {{UserConfigurationImpl.getValidators}} (/)
- importXML (as mentioned above) (/)
- cache only created for users (but not for groups... at least that was the
original intention) (/)
- just for completeness: API calls on {{PrincipalManager}} must have the same
effect (/)
- calling the API calls with a non-system session must never read from the
cache in order to prevent information leakage compared to the non-cached calls,
which are secured by access evaluation (/)
- the group {{Principal}}s as obtained from the cached information read path
and membership information lazily from the corresponding group-authorizable. if
the latter has been removed in the meantime those calls must not result in
runtime exceptions (/)
was (Author: anchela):
continued working on this and found more missing test:
- {{UserConfigurationImpl.getValidators}} (/)
- importXML (as mentioned above) (/)
- cache only created for users (but not for groups... at least that was the
original intention) (/)
- just for completeness: API calls on {{PrincipalManager}} must have the same
effect (/)
- calling the API calls with a non-system session must never read from the
cache in order to prevent information leakage compared to the non-cached calls,
which are secured by access evaluation (/)
> Improve login performance with huge group membership
> ----------------------------------------------------
>
> Key: OAK-3003
> URL: https://issues.apache.org/jira/browse/OAK-3003
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: angela
> Assignee: angela
> Labels: performance
> Attachments: OAK-3003.patch, OAK-3003_2.patch, OAK-3003_3.patch,
> group_cache_in_userprincipalprovider.txt
>
>
> As visible when running {{LoginWithMembershipTest}} default login performance
> (which uses the {{o.a.j.oak.security.principal.PrincipalProviderImpl}} to
> lookup the complete set of principals) suffers when a given user is member of
> a huge number of groups (see also OAK-2690 for benchmark data).
> While using dynamic group membership (and thus a custom {{PrincipalProvider}}
> would be the preferable way to deal with this, we still want to optimize
> {{PrincipalProvider.getPrincipals(String userId}} for the default
> implementation.
> With the introduction of a less generic implementation in OAK-2690, we might
> be able to come up with an optimization that makes use of the very
> implementation details of the user management while at the same time being
> able to properly secure it as we won't need to extend the public API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
