jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-2950) CachingEntryCollector ineffective if number of accessed policies exceeds cache size
Date Tue, 12 Jun 2012 16:20:43 GMT

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

Julian Reschke commented on JCR-2950:
-------------------------------------

I believe we have a remaining issue in updateCache (which previously was synchronized):

{code}
    private Entries updateCache(NodeImpl node) throws RepositoryException {
        Entries entries = super.getEntries(node);
        if (!entries.isEmpty()) {
            // find the next access control ancestor in the hierarchy
            // 'null' indicates that there is no ac-controlled ancestor.
            NodeId nextId = null;
            NodeImpl n = node;
            while (nextId == null && !rootID.equals(n.getNodeId())) {
                if (cache.containsKey(n.getNodeId())) {
                    nextId = n.getNodeId();
                } else if (cache.containsKey(n.getParentId())) {
                    nextId = n.getParentId();
                } else {
                    n = (NodeImpl) n.getParent();
                    if (hasEntries(n)) {
                        nextId = n.getNodeId();
                    } // else: not access controlled -> test next ancestors
                }
            }

            // adjust the 'nextId' to point to the next access controlled
            // ancestor node instead of the parent and remember the entries.
            entries.setNextId(nextId);
            cache.put(node.getNodeId(), entries);
        } // else: not access controlled -> ignore.
        return entries;
    }
{code}

In here, if updateCache is done concurrently with the same node, we may end up finding a cache
entry for the node in the cache, and then update the "nextid" to the node itself. I believe.
                
> 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.4
>         Environment: Repository with ACEs > 1000
>            Reporter: Honwai Wong
>            Assignee: angela
>         Attachments: CachingEntryCollector.ConcurrentCache-trunk.patch, JCR-2950-refactor+rootnode.patch,
JCR-2950-refactor+rootnode_2.patch , JCR-2950-refactor.patch
>
>
> 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