Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Mon, 25 Jun 2012 12:46:42 +0000 (UTC)
From: "Marcel Reutegger (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <1199443472.50772.1340628402916.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1769720781.19134.1339776162397.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (JCR-3345) ACL evaluation may return non-fresh
 results
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Marcel Reutegger commented on JCR-3345:
---------------------------------------

bq. marcel, what about the performance tests? 

I didn't run those tests because I was rather focusing on why the tests fail with those additional sessions reading from the workspace.
                
> 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-pre-populate-cache.patch, JCR-3345.patch, 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