[
https://issues.apache.org/jira/browse/JCR-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613698#comment-13613698
]
angela commented on JCR-3541:
-----------------------------
other contexts? i am not aware of other contexts the ac provider would be used.
the interfaces you are mentioning are not part
of the jackrabbit API and thus should never be used or instantiated outside of
their original scope.
feel free to reopen and attach test-cases that illustrate on how to reproduce
the issue with jackrabbit-core. thanks
> 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
