jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hitesh Shah (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-964) Cannot rebuild corrupt or missing search index from DataSource
Date Mon, 13 Aug 2007 22:59:31 GMT

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


Mime
View raw message