jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mete Atamel <mata...@adobe.com>
Subject Re: MongoMK: CommitCommandInstructionVisitor
Date Wed, 09 Jan 2013 11:15:25 GMT
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.


On 1/9/13 12:04 PM, "Marcel Reutegger" <mreutegg@adobe.com> 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 
>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
>maybe that's the reason why it results in this exception?
> marcel 
>> -----Original Message-----
>> From: Marcel Reutegger [mailto:mreutegg@adobe.com]
>> Sent: Mittwoch, 9. Januar 2013 11:29
>> To: oak-dev@jackrabbit.apache.org
>> Subject: RE: MongoMK: CommitCommandInstructionVisitor
>> > I guess this makes sense, although I'm curious what MicroKernelIT
>> > 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

View raw message