Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <2546355.1187022932471.JavaMail.jira@brutus>
Date: Mon, 13 Aug 2007 09:35:32 -0700 (PDT)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
 search index from DataSource
In-Reply-To: <22260258.1181073146149.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519468 ] 

Stefan Guggisberg commented on JCR-964:
---------------------------------------

> 'm getting the same error, and my environment is not clustered yet. I have removed the SearchIndex capability from my repository.xml file for performance and clustering considerations (we plan on clustering in the production setup). I'm only mentioning this because the "shut down -- remove index directories -- restart" option is not relevant in my case.

are you saying you're able to reproduce this issue in a non-clustered setup? so far we've been unable to do so,
either cluster * non-clustered.
.
could you please provide a simple test case or simple instructions how to reproduce this issue (i.e. failure to 
rebuild index)?

> Cannot rebuild corrupt or missing search index from DataSource
> --------------------------------------------------------------
>
>                 Key: JCR-964
>                 URL: https://issues.apache.org/jira/browse/JCR-964
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: indexing
>    Affects Versions: 1.3
>            Reporter: Noah Vihinen
>            Priority: Blocker
>
> If the search index becomes corrupt, and the auto-repair process cannot fix the search index (which is common in our experience), there is no way to recover the jackrabbit instance.  The only possible work-around is when you're working with a cluster, and you manually copy an intact index from one of the other clusters.  It hasn't been determined whether this leads to other issues though.
> Given a Jackrabbit repository, shouldn't it be possible to start the repository on top of that single data source in the absence of a search index, and have the search index rebuilt from the information in the DB?
> Below is the stack trace we get when restarting a repository with no search index.
> 15:32:13,622 ERROR RepositoryImpl:389 - [main] Failed to initialize workspace 'default'
> javax.jcr.RepositoryException: Error indexing root node: a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: a7479d92-4b59-4f44-978a-06da1ec7b8d1
>         at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:476)
>         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.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:81)
>         at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
>         at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
>         at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
>         at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137)
>         at javax.naming.InitialContext.lookup(InitialContext.java:351)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.