jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Podatelev <brightnesslev...@gmail.com>
Subject Index corruption
Date Tue, 02 Feb 2010 13:10:34 GMT
Hello,

I'm using Jackrabbit 1.5.3 and sometimes I run into index corruption
problem. I can't consistently reproduce the issue, so upgrading to 1.6
or 2.0 is not an option for me, as I'm not sure my exact issue is
solved there.
I'm also not in the liberty of exposing my actual repository
structure, so what I'm asking here is some pointers where exactly too
look at.

Okay, here goes.
The structure of the repo is the following:

jcr:root <- Node 1 <- Node 2 <- Node 3

The scenario at which I'm (sometimes) getting this corruption is the following:

- move Node 3 to be the kid of Node 1
- remove Node 2
- save session
- remove Node 3
- SS
- append Node 4 to Node 1
- SS
- append Node 5 to Node 4
- SS

- perform processing of the resulting tree, which includes reading the
tree and properties being added and removed to all nodes sequentially.
once each node is processed, session.save() is called;

During the processing, I sometimes get the following exception:

2010-01-29 21:39:50,456 DEBUG observation.ObservationDispatcher -
notifying 3 synchronous listeners.
2010-01-29 21:39:50,456 DEBUG core.SearchManager - onEvent: indexing started
2010-01-29 21:39:50,461 WARN  lucene.SearchIndex - Exception while
creating document for node: 1cea61c4-8e20-4aed-b1f2-21600ff65101:
javax.jcr.RepositoryException: Error while indexing node:
1cea61c4-8e20-4aed-b1f2-21600ff65101 of type:
{http://www.jcp.org/jcr/nt/1.0}unstructured:
1cea61c4-8e20-4aed-b1f2-21600ff65101/{}date-updated:
1cea61c4-8e20-4aed-b1f2-21600ff65101/{}date-updated

It is this exception which leads to corrupted index once the
processing is done. If it's thrown during the processing, I then have
query that looks like "//Node" (which is supposed to return 3 elements
currently representing the "tree") only return one element -- Node 1.

Perhaps it also worth noticing that besides this "Node N" elements,
there's a subtree of about 10-15MB of data in the repo, not sure if
this is relevant.

Anyway, if someone can give me any insights regarding what might cause
this issue or how can I reproduce it consistently, that would be
great.

Manually removing index files from fs datastore and restarting the app
is not a suitable workaround for me.



-- 
sp

Mime
View raw message