[
https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515995
]
Stefan Guggisberg commented on JCR-964:
---------------------------------------
> Noah Vihinen commented on JCR-964:
> ----------------------------------
>
> Let me correct some of my previous comments. While trying to reproduce this
> situation yesterday within a non-clustered repository, both indexes were
> re-buildable when I left the working repository directory intact. It
> contains information about custom node schema and custom namespaces, which I
> was previously unaware of. I was expecting that this information was
> persisted by the persistence manager (in my DB).
that's expected behaviour. the repository home directory stores, apart from the
indices, repository internal state (such as custom node types, registered
namespaces etc. ). you're not supposed to delete those directories/files.
however, you could configure jackrabbit to use a virtual database file system
instead of the local file system. everything except the
re-buildable index would then be stored in the database.
there are a couple of threads covering this topic in the mailing lists, see e.g.
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/4647/focus=4649
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/2229/focus=2237
>
> With that said, we still believe that we managed to get our cluster of 4
> repositories into a state where the search index could not be rebuilt by
> shutting down, removing all index directories, and restarting. When we
> reproduce this situation, we will attempt to get more information.
any news on this? anyway, this seems to be a different, i.e. clustering related
issue. we should probably adjust the subject or create a new issue.
> 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.
