ah OK, I see. thanks for the clarification. It looks like there's a bug in getMostRecentValidNodes() though. instead of:
if (!commits.containsKey(revisionId) && nodeStore.getFromCache(revisionId) != null) I think it should rather do: if (!commits.containsKey(revisionId) && nodeStore.getFromCache(revisionId) == null) WDYT? regards marcel > -----Original Message----- > From: Mete Atamel [mailto:[email protected]] > Sent: Mittwoch, 9. Januar 2013 12:15 > To: [email protected] > Subject: Re: MongoMK: CommitCommandInstructionVisitor > > 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.CommitCommandInstructi > onVis > >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
