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