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" <[email protected]> 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
