[jira] [Commented] (JCR-2943) UserManagement: membership cache default size too small

["Honwai Wong (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019244#comment-13019244 ] 

Honwai Wong commented on JCR-2943:
----------------------------------

For transparency reasons, it'd be good to have some debug logging in place which allows one to monitor the cache's efficiency, e.g. cache hit or miss. If it is not too expensive to get the actual id of the authorizable in question, it'd be great to output this as part of the debug message as well.

> UserManagement: membership cache default size too small
> -------------------------------------------------------
>
>                 Key: JCR-2943
>                 URL: https://issues.apache.org/jira/browse/JCR-2943
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: security
>    Affects Versions: 2.2.0, 2.2.1, 2.2.2, 2.2.4
>         Environment: Repository with users being member of over 150 groups
>            Reporter: Honwai Wong
>            Assignee: angela
>             Fix For: 2.3.0
>
>
> The membership cache that has been introduced in JCR-2703 is making use of an LRUMap to cache group memberships (authorizable nodeId -> group nodeIds). In environments where users belong to more than 100 groups, the cache quickly becomes ineffective due to the default maximum size of the LRUMap.
> Once the cache limit is hit, the rather expensive Node#getWeakReferences API calls resulting in search queries are executed again, leading to quite noticeable performance drops. Thus I'd suggest to either make the membership cache configurable or introduce some logic to let the cache grow dynamically as needed (still having some kind of hard limit to avoid memory issues).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira