[
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)
