[
https://issues.apache.org/jira/browse/JCR-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-2950:
------------------------
Attachment: JCR-2950_entryseparation.patch
yet another patch that will allow us to try further improvements later on: the
patch adds complete separation of entries used for permission eval from ACEs
exposed on the JCR API level. consequently i had to rewrite the retrieval of
effective policies (that were using the entry collector as well). in addition i
had to remove the EntryCollectorTest#testIsCached as they were relying on the
effective policies actually exposing the entries in the cache. this is no
longer the case for the reason above.
this patch most probably doesn't add a major performance gain itself, but it
really reduces the entries stored in the cache to the information required for
permission-eval omitting all additional stuff that is used for JCR API
compliance. in addition it would allow us try if it was beneficial to use
multiple sessions to collect the entries.
> 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: angela
> 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.patch, JCR-2950_performance_tests.patch.gz
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
