You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2011/04/28 10:34:03 UTC

[jira] [Commented] (JCR-2950) Performance bottleneck: cache of CachingEntryCollector ineffective in case many ACEs are present

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

angela commented on JCR-2950:
-----------------------------

this issue can only be fixed by fundamental refactoring of the ac storage and evaluation mechanism that would render the cache superfluous (see JCR-2842 for some initial thoughts). increasing the cache size cannot be considered a fix of the generic problem that the cache will become ineffective with "many ACEs".


> Performance bottleneck: cache of CachingEntryCollector ineffective in case many ACEs are present
> ------------------------------------------------------------------------------------------------
>
>                 Key: JCR-2950
>                 URL: https://issues.apache.org/jira/browse/JCR-2950
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core, security
>    Affects Versions: 2.2.4
>         Environment: Repository with ACEs > 1000
>            Reporter: Honwai Wong
>
> The CachingEntryCollector's cache (LRUMap, max size: 1000) seems to become ineffective in case there are more than 1000 ACEs present in the repository. Since access to the cache is synchronized, many threads are basically blocked, waiting to get access to the cache.
> Java callstack:
> at org/apache/jackrabbit/core/security/authorization/acl/CachingEntryCollector.getEntries(CachingEntryCollector.java:99(Compiled Code))
> at org/apache/jackrabbit/core/security/authorization/acl/EntryCollector.collectEntries(EntryCollector.java:134(Compiled Code))
> at org/apache/jackrabbit/core/security/authorization/acl/CompiledPermissionsImpl.canRead(CompiledPermissionsImpl.java:250(Compiled Code))
> at org/apache/jackrabbit/core/security/DefaultAccessManager.canRead(DefaultAccessManager.java:251(Compiled Code))
> at org/apache/jackrabbit/core/ItemManager.canRead(ItemManager.java:426(Compiled Code))
> at org/apache/jackrabbit/core/ItemManager.createItemData(ItemManager.java(Compiled Code))
> at org/apache/jackrabbit/core/ItemManager.getItemData(ItemManager.java:379(Compiled Code))
> at org/apache/jackrabbit/core/ItemManager.itemExists(ItemManager.java:292(Compiled Code))
> at org/apache/jackrabbit/core/ItemManager.itemExists(ItemManager.java:464(Compiled Code))
> at org/apache/jackrabbit/core/session/SessionItemOperation$1.perform(SessionItemOperation.java:49(Compiled Code))
> at org/apache/jackrabbit/core/session/SessionItemOperation$1.perform(SessionItemOperation.java:46(Compiled Code))
> at org/apache/jackrabbit/core/session/SessionItemOperation.perform(SessionItemOperation.java:187(Compiled Code))
> at org/apache/jackrabbit/core/session/SessionState.perform(SessionState.java:200(Compiled Code))
> at org/apache/jackrabbit/core/SessionImpl.perform(SessionImpl.java:355(Compiled Code))
> at org/apache/jackrabbit/core/SessionImpl.itemExists(SessionImpl.java:751(Compiled Code))

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