[
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
