You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Honwai Wong (JIRA)" <ji...@apache.org> on 2011/04/13 09:16:05 UTC
[jira] [Created] (JCR-2943) UserManagement: membership cache
default size too small
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.4, 2.2.2, 2.2.1, 2.2.0
Environment: Repository with users being member of over 150 groups
Reporter: Honwai Wong
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
[jira] [Updated] (JCR-2943) UserManagement: membership cache
default size too small
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-2943:
------------------------
Fix Version/s: 2.3.0
> 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
[jira] [Commented] (JCR-2943) UserManagement: membership cache
default size too small
Posted by "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
[jira] [Assigned] (JCR-2943) UserManagement: membership cache
default size too small
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela reassigned JCR-2943:
---------------------------
Assignee: angela
> 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
[jira] [Resolved] (JCR-2943) UserManagement: membership cache
default size too small
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-2943.
-------------------------
Resolution: Fixed
use the growing lru map functionality used by michael in the ac evaluation.
however, i didn't add additional debug information since the node identifier didn't
seem to be useful from my point of view.
> 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: jackrabbit-core, 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
[jira] [Updated] (JCR-2943) UserManagement: membership cache
default size too small
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated JCR-2943:
------------------------
Component/s: jackrabbit-core
> 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: jackrabbit-core, 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