[jira] [Updated] (OAK-11184) Reading root with an unmerged revision as the only visible revision of a property results in previous document scan

["Stefan Egli (Jira)" <ji...@apache.org>]

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

Stefan Egli updated OAK-11184:
------------------------------
    Summary: Reading root with an unmerged revision as the only visible revision of a property results in previous document scan  (was: Reading root with an unmerged revision results in previous document scan)

> Reading root with an unmerged revision as the only visible revision of a property results in previous document scan
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: OAK-11184
>                 URL: https://issues.apache.org/jira/browse/OAK-11184
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: documentmk
>            Reporter: Stefan Egli
>            Priority: Major
>
> Consider a scenario with 2 cluster nodes (running DocumentNodeStore):
>  * cluster node A with cluster node id 1
>  * cluster node B with cluster node id 2
> Now cluster node A is doing a merge that includes changes (eg a property) on root. Such a merge includes two updates towards DocumentStore:
>  * the first update has the actual changes on the properties (that would include any other document other than root - but that's not so relevant here). Say that happens with revision {{"rn-0-1"}}
>  * the second update is marking the revision as committed - which is done by adding an entry to "_revisions" with {{"rn-0-1" : "c"}}
> If cluster node B reads the root document ("0:/") between the above two steps, it will read {{"rn-0-1"}} in an unmerged state (it has no commit value yet).
> -When B tries to resolve the commit value of {{"rn-0-1"}} it can't find it in the main root document and thus, if there are any, it has to go through the previous documents to see if the revision is there.-
> -In other words: B is taking a performance hit when resolving {{"rn-0-1"}} as it has to go through previous documents.-
> Correction: When B tries to {{getNodeAtRevision}} it sees this new property, resolves the commit value of "rn-0-1". It does find the commit value pretty quickly though, as it's not in the main document but also not in any previous document ranges. However, once it finds the commit value being null, it realizes that there is no valid value in the main document. When presented with this situation it greedily reads through previous documents to {*}find a split-away property value{*}. So it's the scanning for a split-away property value in previous documents, not the scanning of the commit value. Either way, it does indeed scan through all previous documents only to find nothing. This is a significant performance hit.
> The root document is read by backgroundRead. So B will take the performance hit until another backgroundRead succeeds.
> backgroundRead requires the exclusive lock on the backgroundOperationLock as part of updating a fresh main root. If B happens to have that exclusive lock occupied by anyone else, it has to wait.
> As part of a regular merge though, the "read/non-exclusive" lock of backgroundOperationLock is acquired.
> If there are a number of threads "ahead" of backgroundRead all acquiring the read-lock of backgroundOperationLock, the backgroundRead will have to wait until all commits are done.
> So if B is in such a situation, with all merge operations when updating root going through previous documents, it can result in an overall significant delay.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)