jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCR-2950) CachingEntryCollector ineffective if number of accessed policies exceeds cache size
Date Wed, 18 Jul 2012 09:08:37 GMT

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

angela edited comment on JCR-2950 at 7/18/12 9:07 AM:
------------------------------------------------------

> Can we share the session pool with CompiledPermissionImpl? 

imo that would make sense... but given the hacks that were required in order to create the
session pool 
within the entry collector, i would suggest that we introduce the pool in a very early state
and prevent
exposing the SystemSession and it's creation to the public: for example while creating the

AccessControlProviderFactoryImpl in DefaultSecurityManager.... e.g. passing a session provider
instead
of a single session.

in any case i would like to keep that separate from my entryseparation patch as it get rather
cumbersome
to sort out changes when the patch gets too big. julian, what do you think?


                
      was (Author: anchela):
    > Can we share the session pool with CompiledPermissionImpl? 

imo that would make sense... but given the hacks that were required in order to create the
session pool 
within the entry collector, i would suggest that we introduce the pool in a very early state
and prevent
exposing the SystemSession and it's creating to the public: for example while creating the

AccessControlProviderFactoryImpl in DefaultSecurityManager.... e.g. passing a session provider
instead
of a single session.

in any case i would like to keep that separate from my entryseparation patch as it get rather
cumbersome
to sort out changes when the patch gets too big. julian, what do you think?


                  
> 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

        

Mime
View raw message