It's true that only commits are marked as failed in MongoMK but when nodes are fetched, their revision ids are checked against commits collection to make sure the revision id is part of a valid commit. See FetchNodesActionNew#getMostRecentValidNodes method.
-Mete On 1/9/13 12:04 PM, "Marcel Reutegger" <[email protected]> wrote: >hmm, it doesn't look that promising right now, but I think >it has to do with how MongoMK retries commits when there >are conflicts. > >with local changes that I have right now, I get a RuntimeException >in CommitCommandInstructionVisitor: > >java.lang.RuntimeException: There's already a child node with name '3' > at >org.apache.jackrabbit.mongomk.impl.instruction.CommitCommandInstructionVis >itor.visit(CommitCommandInstructionVisitor.java:100) > >that's a bit strange, because the test makes sure that each thread >adds a distinct child node. I suspect the commit is retried (possibly) >multiple times and then sees previous commits or nodes that should be >marked as failed. actually only commits will be marked as failed in >MongoMK. >maybe that's the reason why it results in this exception? > >regards > marcel > >> -----Original Message----- >> From: Marcel Reutegger [mailto:[email protected]] >> Sent: Mittwoch, 9. Januar 2013 11:29 >> To: [email protected] >> Subject: RE: MongoMK: CommitCommandInstructionVisitor >> >> > I guess this makes sense, although I'm curious what MicroKernelIT >>tests >> > would fail if we simply change headRevisionId in >> > CommitCommandInstructionVisitor to baseRevisionId of Commit. >> >> I'll try that out. >> >> > I'm thinking >> > about the case where the passed in revision id is null and also other >> > cases where there are conflicting moves/adds/deletes. >> >> I think in this case we'd still use the head revision. >> >> regards >> marcel
