You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Geoffroy Schneck (JIRA)" <ji...@apache.org> on 2014/11/03 14:06:34 UTC
[jira] [Commented] (JCR-2950) CachingEntryCollector ineffective if
number of accessed policies exceeds cache size
[ https://issues.apache.org/jira/browse/JCR-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194515#comment-14194515 ]
Geoffroy Schneck commented on JCR-2950:
---------------------------------------
This issue is till not marked as Fixed, however there are a lot of patches available . What is the exact status ? Does one of the attached patch led to performance improvement ?
> CachingEntryCollector ineffective if number of accessed policies exceeds cache size
> -----------------------------------------------------------------------------------
>
> 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.12, 2.4.2, 2.6
> Environment: Repository with ACEs > 1000
> Reporter: Honwai Wong
> Assignee: Julian Reschke
> Attachments: CachingEntryCollector.ConcurrentCache-trunk.patch, JCR-2950-concurrent-cache-2.patch, JCR-2950-futures.patch, JCR-2950-futures_2.patch, JCR-2950-futures_3.patch, JCR-2950-futures_4.patch, JCR-2950-refactor+rootnode.patch, JCR-2950-refactor+rootnode_2.patch , JCR-2950-refactor+rootnode_3.patch, JCR-2950-refactor+rootnode_4.patch, JCR-2950-refactor+rootnode_5.patch, JCR-2950-refactor+rootnode_6.patch, JCR-2950-refactor+rootnode_7.patch, JCR-2950-refactor.patch, JCR-2950-throttle.patch, JCR-2950-throttle2.patch, JCR-2950_entryseparation-multisessionhack.patch, JCR-2950_entryseparation.patch, JCR-2950_performance_tests.patch.gz, auth-prefilled-cache.csv, cache-empty-aces-scfixed.csv, cache-empty-aces.csv, cache-empty-aces.png, jcr-2950-2.csv, jcr-2950-2.png, jcr-2950-csv.sh, jcr-2950.csv, jcr-2950.png, syssessioncomparison.csv, test2950.sh
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)