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

Mete Atamel commented on OAK-560:
---------------------------------

Hmm, not sure, maybe. But now I think the problem might be something else. When 
the merge commit is being generated, the current head revision is used as base 
revision id. That's problematic because current head revision can become 
invalid later. I think instead, it should use branch root revision id because 
that's what the merge is based on really and when the merge commit happens, it 
shouldn't really worry about whether it's part of a branch or not, unlike other 
commits. Initial tests are good, I'll attach a patch soon. Not sure if it get 
rids of the problem all together but it definitely helps.
                
> MongoMK.commit() not atomic
> ---------------------------
>
>                 Key: OAK-560
>                 URL: https://issues.apache.org/jira/browse/OAK-560
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: mongomk
>    Affects Versions: 0.5
>            Reporter: Marcel Reutegger
>            Priority: Critical
>
> I created a test (rev 1433995), while reasoning about the optimization we are 
> working on in OAK-535. It seem it uncovers a race condition in the commit 
> command. I was already wondering in the past if something like this can 
> happen, and now it looks like there is indeed a problem.
> Without having further analyzed the sporadic test failure I see, I think it 
> is caused by the optimistic commit protocol implemented in CommitCommandNew. 
> The internal retry loop saves the nodes, then saves the commit and finally 
> save head revision. IIUC this exposes a commit even though it is not yet 
> valid and the command may flag it as failed later when it cannot save the 
> head revision. And this is indeed the case when I set a breakpoint for the 
> failed commit and look inside the commits collection I can see that the 
> commit in question is flagged as failed.
> The exception then looks like this:
> org.apache.jackrabbit.mk.api.MicroKernelException: java.lang.Exception: 
> Commit with revision 134 could not be found
>       at 
> org.apache.jackrabbit.mongomk.impl.MongoMicroKernel.merge(MongoMicroKernel.java:214)
>       at 
> org.apache.jackrabbit.mongomk.impl.MongoMKBranchMergeTest$1.run(MongoMKBranchMergeTest.java:362)
>       at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.Exception: Commit with revision 134 could not be found
>       at 
> org.apache.jackrabbit.mongomk.impl.action.FetchCommitAction.execute(FetchCommitAction.java:65)
>       at 
> org.apache.jackrabbit.mongomk.impl.command.CommitCommandNew.readBranchIdFromBaseCommit(CommitCommandNew.java:145)
>       at 
> org.apache.jackrabbit.mongomk.impl.command.CommitCommandNew.execute(CommitCommandNew.java:96)
>       at 
> org.apache.jackrabbit.mongomk.impl.command.CommitCommandNew.execute(CommitCommandNew.java:56)
>       at 
> org.apache.jackrabbit.mongomk.impl.command.MergeCommand.execute(MergeCommand.java:118)
>       at 
> org.apache.jackrabbit.mongomk.impl.command.MergeCommand.execute(MergeCommand.java:51)
>       at 
> org.apache.jackrabbit.mongomk.impl.command.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:38)
>       at 
> org.apache.jackrabbit.mongomk.impl.MongoNodeStore.merge(MongoNodeStore.java:146)
>       at 
> org.apache.jackrabbit.mongomk.impl.MongoMicroKernel.merge(MongoMicroKernel.java:212)
>       ... 2 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to