jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Asynchronous indexing consistency
Date Wed, 29 May 2013 09:28:18 GMT
Hi,

What would happen if you stop a cluster node for a long time (for example
1 day)? Would async indexing be done on another cluster node? If yes, I
guess we need a way to ensure that's the case. If not, then the problem
might be that old revisions are no longer available.

I guess we need a similar mechanism for the JCR EventJournal. (Or we could
store the event journal as separate nodes, but that would need more space).

By the way, for the MongoMK, we need a mechanism to clean up garbage of
crashed cluster nodes. As we anyway need it, we might as well use it for
other features.

Regards,
Thomas



On 5/29/13 11:06 AM, "Alex Parvulescu" <alex.parvulescu@gmail.com> wrote:

>hi guys,
>
>I'm trying to find a solution for keeping the async index up to date in
>the
>case where the system restarts.
>How can the indexing process pick up where it left off?
>
>A quick chat with Jukka turned up some ideas, but be warned this is all
>based on api changes:
>
> - expose the revision info and make it usable from the NodeStore.
>The indexer would need to access the rev info, eventually store it, use it
>as a reference when creating a new index branch.
>
> - have a persistent (not garbage collected) branch dedicated to the async
>indexer, which it can reuse even after a restart, eventually dispose of it
>when the indexing process is done with.
>This is an optimization of the entire index branch creation bits.
>
>So, missing apis:
> - revision info in the NodeState,
> - possibility to get the NodeState given a revision, (so that we can have
>the diff from rev to head)
> - branch creation with a name, branch retrieval by name, branch delete by
>name
>
>
>thanks,
>alex


Mime
View raw message