[ 
https://issues.apache.org/jira/browse/OAK-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945683#comment-16945683
 ] 

Marcel Reutegger commented on OAK-8623:
---------------------------------------

Those tests use the default Clock implementation and fail when the timestamp of 
the branch commit is equal to the subsequent startup timestamp of the 
DocumentNodeStore. Switching to a virtual clock and calling 
{{Clock.getTimeIncreasing()}} ensures those two timestamps are different.

There is another problem with the test. Though, it happens a lot less likely. 
The branch commit may get cleaned up on {{DocumentNodeStore.dispose()}}. This 
is fixed as well by adding a method to the test that retains references to 
branches that have not been merged.

Fixed in trunk: http://svn.apache.org/r1868076

> Improve collision handling performance
> --------------------------------------
>
>                 Key: OAK-8623
>                 URL: https://issues.apache.org/jira/browse/OAK-8623
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: documentmk
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Major
>             Fix For: 1.20.0
>
>         Attachments: OAK-8623-2.patch, OAK-8623.patch
>
>
> The current collision handling on conflict in the DocumentNodeStore can be 
> rather expensive when there are old branch commits which were not merged.
> A commit that includes documents with old branch commits that have not been 
> merged will always attempt to set a collision marker on the commit root 
> document for those changes.
> While it is difficult to tell whether a branch commit will be merged at some 
> point, at least those branch commits that were created before the most recent 
> startup of a cluster node cannot be merged. The collision handling logic 
> could be improved to take the start time of a cluster node into account.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to