Hi, Just a few clarifications on the error you see
> My interpretation is that the AsyncIndexUpdate is trying to retrieve the previous checkpoint as stored in /:async/async. Of course this checkpoint is not present in the copied NodeStore and thus cannot be retrieved. The error comes from DocumentMk trying to parse the reference checkpoint value. Basically what fails here is 'Revision.fromString' receiving a malformed checkpoint value because it comes from the SegmentMk. The quick fix is to manually remove the properties on the "/:async" hidden node. This will indeed trigger a full reindex, but will help you getting over this issue. > IMHO it would be desirable to (optionally) copy the checkpoints as well. In the case of AsyncIndexUpdate, having the checkpoint can save a full re-index. This is very tricky, as the 2 representations of checkpoints between SegmentMk and DocumentMk are quite different. I would strongly suggest going for the reindex, after all you'd only migrate once, so you can prepare for this lengthy process. best, alex On Wed, Aug 5, 2015 at 3:35 PM, Julian Sedding <jsedd...@gmail.com> wrote: > Hi all > > I am working on a scenario, where I need to copy a SegmentNodeStore > (TarMK) to a DocumentNodeStore (MongoDB). > > It is pretty straight forward to simply copy the NodeStore via the > API. No problems here. > > In a recent experiment I successfully copied the NodeStore and got an > exception in the logs (stacktrace below the email). > > My interpretation is that the AsyncIndexUpdate is trying to retrieve > the previous checkpoint as stored in /:async/async. Of course this > checkpoint is not present in the copied NodeStore and thus cannot be > retrieved. > > IMHO it would be desirable to (optionally) copy the checkpoints as > well. In the case of AsyncIndexUpdate, having the checkpoint can save > a full re-index. > > The question that remains is how the internal state of > AsyncIndexUpdate should be modified: > * implementing the logic in oak-upgrade would be pragmatic, but > distributes knowledge about AsyncIndexUpdate implementation details to > different modules > * having a CommitHook/Editor in oak-core that can be used in > oak-upgrade might be cleaner, but would only get used in oak-upgrade > > Other ideas and opinions regarding this feature are more than welcome! > > Regards > Julian > > > 05.08.2015 00:03:19.133 *ERROR* [pool-6-thread-2] > org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception > during job execution of > org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate@471e4b4b : > 91f7e218-6cf5-4a44-a324-f094c29898e6 > java.lang.IllegalArgumentException: 91f7e218-6cf5-4a44-a324-f094c29898e6 > at > org.apache.jackrabbit.oak.plugins.document.Revision.fromString(Revision.java:236) > at > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.retrieve(DocumentNodeStore.java:1570) > at > org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:279) > at > org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:105) > at org.quartz.core.JobRunShell.run(JobRunShell.java:202) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) >
