[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643941#comment-14643941
]
angela commented on OAK-3003:
-----------------------------
[~lbyrum], i think there is a mistunderstanding wrt the ability to manually
create the cache: this is _not_ possible as you can see both in the code and
the documentation and the test-cases. this cache is system-maintained and
must/can never be created/updated from an application irrespective of the
permissions present. this is indicated by the fact that all properties it
contains are 'protected'. if the sling content distribution doesn't check for
the item definitions to identify if a given property/node is protected before
attempting to write it, it is just simply broken and will also fail for other
parts. so, in other words: if the content distribution is working according to
the API contract it should not deal with the cache properties anyway and if it
attempts to do so, it must be fixed.
> 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, OAK-3003_2.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)
