Opened https://issues.apache.org/jira/browse/JCR-964 as this seems to
be a blocker for us, until we can figure out how to rebuild an index
from information in our DB.
On Jun 5, 2007, at 7:21 AM, Noah Vihinen wrote:
OK, that makes sense. However my main question is how do I recover
from a corrupt search index? The automatic repair that seems to
kick in on a restart notifies me that the index cannot be
repaired. It seems like a DB backup is not enough, and I also have
to back up my file-based search indexes. This seems bad, as it
will be nearly impossible to take these two backup snapshots of two
persistent stores in the same state.
On Jun 4, 2007, at 5:05 AM, Marcel Reutegger wrote:
Hi Noah,
Noah Vihinen wrote:
We've been running into issues with our jackrabbit index on
forced shutdowns. On restarts, we end up getting errors like the
following:
Error indexing root node:
java.io.IOException: Error indexing root node:
b5d9c4a1-07d5-471e-9fc9-e9a2fbd6ae48
at
org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>
(MultiIndex.java:313) at
org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit
(SearchIndex.java:295) at
org.apache.jackrabbit.core.query.AbstractQueryHandler.init
(AbstractQueryHandler.java:44)
[...]
We attempted to get around this issue by simply deleted the index
of the repository (on the particular machine in a cluster) and
restarted with no luck. In the end, the only thing that seems to
work is to copy the index directory from one of the other
functional machines in our cluster, followed by a restart.
This seems like a really ugly way of getting around this issue.
Is there something obvious we're doing wrong. Shouldn't it be
possible to add a machine to a cluster with no pre-existing
index? What are we missing?
My guess is, that this happens because content is changed while
the new cluster node indexes (traverses) the workspace.
Might be related to: http://issues.apache.org/jira/browse/JCR-931
regards
marcel
