jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3345) ACL evaluation may return non-fresh results
Date Wed, 20 Jun 2012 15:35:42 GMT

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

Marcel Reutegger commented on JCR-3345:

This is related to JCR-2813, which set to fixed, but apparently it still happens. I can see
the WARN message in the logs when I run the test:

WARN  [main] ItemStateReferenceCache.java:176  overwriting cached entry e8248005-46cb-445f-aa13-a4b0bc8f3a65

Debugging the system session shows that the aclNode (with UUID e8248005-46cb-445f-aa13-a4b0bc8f3a65
in my test run) refers to a NodeState that has an overlayed state, which is not up-to-date.
It is missing an access control entry child node that was added in the test. Further analyzing
the cache of the SharedItemStateManager shows that the NodeState for aclNode in there in fact
has the correct number of child nodes.
> ACL evaluation may return non-fresh results
> -------------------------------------------
>                 Key: JCR-3345
>                 URL: https://issues.apache.org/jira/browse/JCR-3345
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, security
>    Affects Versions: 2.6
>            Reporter: Julian Reschke
>         Attachments: JCR-3345.test.patch
> It appears that changes to access control entries are not always visible right away;
in particular not to the session that caused them.
> EntryCollectorTest has recently been extended to run the existing set of tests under
load as well, and occasionally we see tests failing because of ACEs not yet being returned.
> Increasing the load (see attached patch for the test) seems to make it easier to reproduce.
> The underlying reason might be that this involves multiple sessions to be in sync.
> Note that the cache in CachingEntryCollector doesn't seem to be the cause; disabling
it by commenting out all write operations to the cache (making everything a cache miss) doesn't
change the outcome.

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


View raw message