[
https://issues.apache.org/jira/browse/OAK-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620198#comment-14620198
]
angela edited comment on OAK-3003 at 7/24/15 4:37 PM:
------------------------------------------------------
thanks for the review:
- exptime: yes... i expect the cache to be invalidated within seconds or
minutes (not milis). i will review this and maybe also make use of
{{ConfigurationParameters.Milliseconds}} that can read human readable durations
- concurrent updates: i will add a test case for that. in case of conflict the
failing update can just revert the changes and use the refreshed root. it
should however never fail the principal lookup (i.e. login) (/) _test added in
OAK-3003_2.patch_
- regarding inconsistencies and missing invalidation: that's actually a
conscious decision as i know there are cases where membership is being changed
so often that it would just render the cache useless. instead it's meant to
have the effect as if the 'same' session would be returned for subsequent
repository logins as it happens in our use case where every single http request
generates a new repository login; in such a scenario changed group membership
doesn't necessarily need to be reflected immediately.
was (Author: anchela):
thanks for the review:
- exptime: yes... i expect the cache to be invalidated within seconds or
minutes (not milis). i will review this and maybe also make use of
{{ConfigurationParameters.Milliseconds}} that can read human readable durations
- concurrent updates: i will add a test case for that. in case of conflict the
failing update can just revert the changes and use the refreshed root. it
should however never fail the principal lookup (i.e. login)
- regarding inconsistencies and missing invalidation: that's actually a
conscious decision as i know there are cases where membership is being changed
so often that it would just render the cache useless. instead it's meant to
have the effect as if the 'same' session would be returned for subsequent
repository logins as it happens in our use case where every single http request
generates a new repository login; in such a scenario changed group membership
doesn't necessarily need to be reflected immediately.
> 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)
