You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/03/26 12:01:15 UTC

[jira] [Resolved] (JCR-3541) Non-negligible probability of deadlock between AbstractCompiledPermissions.monitor and other actors

     [ https://issues.apache.org/jira/browse/JCR-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela resolved JCR-3541.
-------------------------

    Resolution: Incomplete
    
> Non-negligible probability of deadlock between AbstractCompiledPermissions.monitor and other actors
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JCR-3541
>                 URL: https://issues.apache.org/jira/browse/JCR-3541
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.5.3
>            Reporter: Lukas Eder
>
> There is a high probability of a deadlock between org.apache.jackrabbit.core.security.authorization.AbstractCompiledPermissions and other actors in jackrabbit-core's internals. The problem lies in the fact that AbstractCompiledPermissions.getResult() holds the monitor for quite a long time:
>         synchronized (monitor) {
>             result = cache.get(absPath);
>             if (result == null) {
>                 if (absPath == null) {
>                     result = buildRepositoryResult();
>                 } else {
>                     result = buildResult(absPath); // Slow operation
>                 }
>                 cache.put(absPath, result);
>             }
>         }
> Implementations might run lots of code within buildResult(), which may eventually invoke the synchronized ItemManager methods, for instance, which themselves have a significant probability of passing through the AbstractCompiledPermissions again.
> I wonder whether synchronization should be limited to cache access, applying double-checked locking as such:
>         Result result;
>         synchronized (monitor) {
>             result = cache.get(absPath);
>         }
>         if (result == null) {
>             if (absPath == null) {
>                 result = buildRepositoryResult();
>             } else {
>                 result = buildResult(absPath);
>             }
>             synchronized (monitor) {
>                 Result r = cache.get(absPath);
>                 if (r == null) {
>                     cache.put(absPath, result);
>                 }
>             }
>         }
>         return result;
> Alternatively, to make things a bit more readable, the cache could be implemented using a ConcurrentHashMap.
> Note, the actual deadlock that I've got was probably due to abusing the Jackrabbit APIs in a custom AccessControlProvider

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira