You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Noah Vihinen <nv...@maven.net> on 2007/06/02 21:57:37 UTC
Removing Index
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)
at
org.apache.jackrabbit.core.SearchManager.initializeQueryHandler
(SearchManager.java:474)
at org.apache.jackrabbit.core.SearchManager.<init>
(SearchManager.java:231)
at org.apache.jackrabbit.core.RepositoryImpl
$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1643)
at org.apache.jackrabbit.core.RepositoryImpl.initWorkspace
(RepositoryImpl.java:633)
at
org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces
(RepositoryImpl.java:386)
at org.apache.jackrabbit.core.RepositoryImpl.<init>
(RepositoryImpl.java:293)
at org.apache.jackrabbit.core.RepositoryImpl.create
(RepositoryImpl.java:584)
at
org.apache.jackrabbit.core.jndi.BindableRepository.createRepository
(BindableRepository.java:174)
at org.apache.jackrabbit.core.jndi.BindableRepository.init
(BindableRepository.java:138)
at org.apache.jackrabbit.core.jndi.BindableRepository.create
(BindableRepository.java:125)
at
org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance
(BindableRepositoryFactory.java:59)
at
org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository
(RegistryHelper.java:60)
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?
Thanks,
Noah
Re: Removing Index
Posted by Noah Vihinen <nv...@maven.net>.
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
>
Re: Removing Index
Posted by Noah Vihinen <nv...@maven.net>.
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
Re: Removing Index
Posted by Marcel Reutegger <ma...@gmx.net>.
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