[jira] [Updated] (OAK-3439) MissingLastRevSeeker potential race condition acquiring the lock

["Julian Reschke (JIRA)" <ji...@apache.org>]

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

Julian Reschke updated OAK-3439:
--------------------------------
    Attachment: OAK-3439.diff

(work in progress)

Surprisingly, the code was handling the case where the ClusterNodeInfo entry did not exist in the first place, so it was implicitly created. This is required for tests that use a clusterId of 0 in which case currently no CNIs are generated; we may want to discuss this.

The right thing to do would be to rely on the documents to be there (why would you acquire a lock on something that does not exist?), and to use UpdateOp.equals() to ensure that the ClusterNodeInfo.REV_RECOVERY_LOCK is set to NONE).

The current patch thus has a workaround for missing ClusterNodeInfo docs to make it compatible with the old behavior.

Note that the condition check would be more robust if we had a NotEquals condition (and that would evaluate to true when a property is not set). (Will open a separate ticket to discuss this)



> MissingLastRevSeeker potential race condition acquiring the lock
> ----------------------------------------------------------------
>
>                 Key: OAK-3439
>                 URL: https://issues.apache.org/jira/browse/OAK-3439
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: core, rdbmk
>            Reporter: Julian Reschke
>         Attachments: OAK-3439.diff
>
>
> {code}
>             // This approach has a race condition where two different cluster
>             // nodes
>             // can acquire the lock simultaneously.
>             UpdateOp update = new UpdateOp(Integer.toString(clusterId), true);
>             update.set(ClusterNodeInfo.REV_RECOVERY_LOCK, RecoverLockState.ACQUIRED.name());
>             store.createOrUpdate(Collection.CLUSTER_NODES, update);
>             return true;
> {code}
> It would be good if could harden this, however it seems that the conditions in UpdateOp only work on revision properties. [~mreutegg] WDYT?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)