[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640115#comment-14640115
]
angela edited comment on OAK-3003 at 7/24/15 7:57 AM:
------------------------------------------------------
[~rr...@adobe.com], [~lbyrum], i would also like to get a quick feedback from
your side, if my analysis of the impact wrt user management API calls and the
Sling content distribution makes sense to you or if you still see potential for
regressions/troubles here (which is obviously the least thing i would wish
given the fact that this an improvement and implementation detail which should
by no means affect the regular API consumers). In the meantime, I will add
another test to make sure that regular XML import (such as used by Jackrabbit
Vault and package managing) does really properly ignore the cache and not
resulting in unexpected regressions.
was (Author: anchela):
[~rr...@adobe.com], [~lbyrum], i would also like to get a quick feedback from
your side, if my analysis of the impact wrt user management API calls and the
Sling content distribution makes sense to you or if you still see potential for
regressions here. In the meantime, I will add another test to make sure that
regular XML import (such as used by Jackrabbit Vault and package managing) does
really properly ignore the cache and not resulting in unexpected regressions.
> 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
> Attachments: OAK-3003.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)
