You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Noah Vihinen (JIRA)" <ji...@apache.org> on 2007/06/05 21:52:26 UTC
[jira] Created: (JCR-964) Cannot rebuild corrupt or missing search
index from DataSource
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: Critical
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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Noah Vihinen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502468 ]
Noah Vihinen commented on JCR-964:
----------------------------------
The behavior is different between SimpleDBPersistenceManager and BundleDBPersistenceManager. Only BundleDBPersistenceManager throws the above exception. With SimpleDBPersistenceManager, the exception doesn't occur on a restart with a removed index. However, all nodes after the restart in a custom namespace are not queryable in this case. They can only be accessed by getting child nodes from a particular node.
> 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.
[jira] Updated: (JCR-964) Cannot rebuild corrupt or missing search
index from DataSource
Posted by "Noah Vihinen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noah Vihinen updated JCR-964:
-----------------------------
Priority: Blocker (was: Critical)
This blocks us from using jackrabbit in a production environment.
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519994 ]
Stefan Guggisberg commented on JCR-964:
---------------------------------------
Hitesh Shah:
your problem definitely seems to be unrelated to this jira issue.
i suggest that you create a new jira issue with a more suitable
summary/description. please provide as much information as
possible, your deployment model, config, test case, instructions
how to reproduce, full stack traces (incl. nested) etc.
thanks
stefan
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514346 ]
Jukka Zitting commented on JCR-964:
-----------------------------------
It should be possible to just remove the index directory and Jackrabbit will automatically recreate it when next started. There might be something else wrong with your repository. At least my experience has been that the reindexing logic is fairly solid, even though it often ends up taking quite a lot of time.
> 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.
[jira] Issue Comment Edited: (JCR-964) Cannot rebuild corrupt or
missing search index from DataSource
Posted by "Hitesh Shah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517524 ]
Hitesh Shah edited comment on JCR-964 at 8/3/07 6:26 AM:
---------------------------------------------------------
I'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.
was:
I'm getting the same error, and my environment is not clustered. I have removed the SearchIndex capability from my repository.xml file for performance and clustering considerations. I'm only mentioning this because the "shut down -- remove index directories -- restart" option is not relevant in my case.
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Hitesh Shah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519548 ]
Hitesh Shah commented on JCR-964:
---------------------------------
I don't have a test case or sample instructions on how to reproduce the issue. It looks like the issue is not what I was expecting either. It looks like there's a different issue, based on the stacktraces I'm seeing on my server log. Maybe this post needs to go into a different thread, but I'm kinda pressed for time to figure out a solution, so I'll let the administrators move me (thanks in advance!!).
Quick rundown of what happens:
JackRabbit is being used as a document repository at my client. Along with the actual document, they also want to store metadata for the document, including filename, document creator, upload timestamp, document category, etc. My design/implementation is to create a node for each document, with a property for each metadata attribute. Only a subset of the fields are user-updatable; most of the fields are immutable.
Documents get created and retrieved just fine, for the most part. However, every once in a while, I get an exception when I'm trying to read one of the user-updatable fields. Most times, it requires a user update to trigger the error; though I have seen instances where the first time I try to access the new document node, I get the error. But, once the error starts occuring for a specific property, it happens consistently for that property.
As far as I know, there is no background database activity on the JackRabbit tables.
Any assistance would be greatly appreciated.
Thanks!!
Here's a sample of my retrieval code:
if (node.hasProperty(DocumentRepositoryConstants.PREFIX_FILENAME))
vb.setFilename(node.getProperty(DocumentRepositoryConstants.PREFIX_FILENAME).getString());
Here's a sample of my insert/update code:
if (vb.getFilename() != null)
node.setProperty(DocumentRepositoryConstants.PREFIX_FILENAME, vb.getFilename());
Here's the stacktrace:
org.apache.jackrabbit.core.state.ItemStateException: failed to read property state: d081fabb-9ddf-41a4-9bba-b607b11a5215/{http:\\www.blah.com\blah\jcr}filename
at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.load(DatabasePersistenceManager.java:392)
at org.apache.jackrabbit.core.state.SharedItemStateManager.loadItemState(SharedItemStateManager.java:1155)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1080)
at org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:252)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getPropertyState(LocalItemStateManager.java:120)
at org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:152)
at org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:226)
at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:175)
at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:493)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:324)
at org.apache.jackrabbit.core.NodeImpl.getProperty(NodeImpl.java:2506)
at MyDocumentRepositoryManager.mapNodeToViewBean(DocumentRepositoryManagerNEW.java:365)
And here's a snippet of my repository.xml configuration file:
<Repository>
<FileSystem class="MySimpleDbFileSystem">
<param name="driver" value="COM.ibm.db2.jdbc.app.DB2Driver" />
<param name="url" value="jdbc:db2:MYDB" />
<param name="user" value="USER" />
<param name="password" value="PASSWORD" />
<param name="schema" value="SCHEMA" />
<param name="schemaObjectPrefix" value="JCR_WS_" />
<param name="externalBLOBs" value="false" />
</FileSystem>
<Security appName="Jackrabbit">
<AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager" />
</Security>
<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default" />
<Workspace name="${wsp.name}">
<FileSystem class="MySimpleDbFileSystem">
<param name="driver" value="COM.ibm.db2.jdbc.app.DB2Driver" />
<param name="url" value="jdbc:db2:MYDB" />
<param name="user" value="USER" />
<param name="password" value="PASSWORD" />
<param name="schema" value="SCHEMA" />
<param name="schemaObjectPrefix" value="JCR_WS_" />
<param name="externalBLOBs" value="false" />
</FileSystem>
<PersistenceManager class="MySimpleDbPersistenceManager">
<param name="driver" value="COM.ibm.db2.jdbc.app.DB2Driver" />
<param name="url" value="jdbc:db2:MYDB" />
<param name="user" value="USER" />
<param name="password" value="PASSWORD" />
<param name="schema" value="SCHEMA" />
<param name="schemaObjectPrefix" value="JCR_WS_" />
<param name="externalBLOBs" value="false" />
</PersistenceManager>
</Workspace>
<!-- Versioning section -->
</Repository>
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Hitesh Shah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517524 ]
Hitesh Shah commented on JCR-964:
---------------------------------
I'm getting the same error, and my environment is not clustered. I have removed the SearchIndex capability from my repository.xml file for performance and clustering considerations. I'm only mentioning this because the "shut down -- remove index directories -- restart" option is not relevant in my case.
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (JCR-964) Cannot rebuild corrupt or missing search
index from DataSource
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg resolved JCR-964.
-----------------------------------
Resolution: Cannot Reproduce
haven't gotten any news from the OP for more than 2 months.
since we've been unable to reproduce this issue i am resolving it now
as 'Cannot Reproduce'.
please feel free to reopen/create a new issue if there's new information.
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Noah Vihinen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502760 ]
Noah Vihinen commented on JCR-964:
----------------------------------
I have a related question. Is any reference to the cluster node ID stored within the jackrabbit work directory (besides in the repository.xml file)?
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Hitesh Shah (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519762 ]
Hitesh Shah commented on JCR-964:
---------------------------------
Update:
When I try to read that property directly out of the db, I get a StreamCorruptedException.
Code snippet:
Class.forName(driver);
connection = DriverManager.getConnection(url, user, password);
ps = connection.prepareStatement(sql);
ps.setString(1, key);
rs = ps.executeQuery();
if (rs.next()) {
byte[] bytes = rs.getBytes(1);
for (int j = 0; j < bytes.length; j++) {
System.out.print(bytes[j]);
System.out.print("\t");
}
System.out.println("");
ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(bytes);
ObjectInputStream in = new ObjectInputStream(byteArrayInputStream);
}
Output:
7 -122 -124 -5 -31 112 48 46 33 4 1 -84 0 -64 1 0 0 0 0 56 2 14
java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:770)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:286)
at ReadCorruptJackrabbitDataTest.execute(ReadCorruptJackrabbitDataTest.java:62)
at ReadCorruptJackrabbitDataTest.main(ReadCorruptJackrabbitDataTest.java:33)
> 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing
search index from DataSource
Posted by "Noah Vihinen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502754 ]
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).
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.
> 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.