jackrabbit-dev mailing list archives

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

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

angela commented on JCR-3345:
-----------------------------

> in particular not to the session that caused them

i don't think that this is the case. the editing session most probably sees the modified ACL
content but the effective acl such as obtained from the system-session associated with the
ac-provider seems not to see the changes at that point. i could even live with that as long
as we could be sure that there were no outdated entries stored in the cache that were properly
updated afterwards. but if it turned out that the the entrycollector got informed about ac
modifications before (-> clearing) and the system session was reading outdated information
on the next permission-eval, that was troublesome.
                
> 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

        

Mime
View raw message