jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-964) Cannot rebuild corrupt or missing search index from DataSource
Date Fri, 27 Jul 2007 09:34:19 GMT

    [ 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.


Mime
View raw message