[
https://issues.apache.org/jira/browse/JCR-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409821#comment-13409821
]
Marcel Reutegger commented on JCR-2950:
---------------------------------------
Tested the patch with the pool of system sessions as well and the numbers are
quite promising. my best cases were around 7 seconds per test iterations. I saw
a lot of threads reading from the derby data base and then tested again with a
bundleCacheSize of 128 (MB). This again reduced the test iteration time to
roughly 5 seconds. The bottleneck now moved to the shared session in
CompiledPermissionImpl:
"Thread-110" prio=10 tid=0x00007f57f924b800 nid=0x4d81 waiting for monitor
entry [0x00007f57fc2dd000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
- waiting to lock <0x00000000e09c8330> (a
org.apache.jackrabbit.core.ItemManager)
at
org.apache.jackrabbit.core.security.authorization.acl.CompiledPermissionsImpl.canRead(CompiledPermissionsImpl.java:241)
- locked <0x00000000e842e130> (a java.lang.Object)
at
org.apache.jackrabbit.core.security.DefaultAccessManager.canRead(DefaultAccessManager.java:265)
at org.apache.jackrabbit.core.ItemManager.canRead(ItemManager.java:438)
at
org.apache.jackrabbit.core.ItemManager.createItemData(ItemManager.java:843)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:391)
at
org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:304)
at
org.apache.jackrabbit.core.ItemManager.itemExists(ItemManager.java:476)
at
org.apache.jackrabbit.core.session.SessionItemOperation$1.perform(SessionItemOperation.java:49)
at
org.apache.jackrabbit.core.session.SessionItemOperation$1.perform(SessionItemOperation.java:46)
at
org.apache.jackrabbit.core.session.SessionItemOperation.perform(SessionItemOperation.java:187)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at
org.apache.jackrabbit.core.SessionImpl.itemExists(SessionImpl.java:803)
> 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-multisessionhack.patch,
> JCR-2950_entryseparation.patch, JCR-2950_performance_tests.patch.gz,
> jcr-2950-2.csv, jcr-2950-2.png, jcr-2950-csv.sh, jcr-2950.csv, jcr-2950.png,
> 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 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
