[
https://issues.apache.org/jira/browse/OAK-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-1471:
----------------------------------
Attachment: OAK-1471.patch
ConcurrentWriteACLTest is in my view a bit problematic because the probability
is quite high that there are conflicts when run with two threads. The test adds
access control entries and immediately after removes them again. This means
e.g. the key rep%3AGrantACE in the node type index is added and removed very
frequently and will lead to conflicts. If there was at least one other
rep:GrantACE this wouldn't be a problem.
I suggest to modify the test as outlined in the patch.
> Mod count in permission store requires cluster wide synchronization
> -------------------------------------------------------------------
>
> Key: OAK-1471
> URL: https://issues.apache.org/jira/browse/OAK-1471
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Reporter: Marcel Reutegger
> Assignee: Tobias Bocanegra
> Priority: Critical
> Fix For: 0.19
>
> Attachments: OAK-1471.patch
>
>
> The current permission store implementation keeps a mod count property on
> some of the nodes to detect changes and update/invalidate a cache when
> required. In general this introduces a contention point when there are
> concurrent modifications of access control entries for a given user. Those
> concurrent changes may introduce conflicts and commits may have to be retried
> after a rebase. This still works somewhat OK when there is just a single oak
> instance, because both segment and document store implementation will
> eventually fall back to locking and serialize the commits. However, it does
> not work well in a cluster, unless we apply the same locking cluster wide.
> See also discussion here:
> http://markmail.org/message/k64udmgc3ctaqmn2
--
This message was sent by Atlassian JIRA
(v6.2#6252)
