jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Index corruption
Date Thu, 04 Feb 2010 17:12:39 GMT
Hi,

is that a single threaded environment or is it possible that multiple
threads share a session? that's not supported.

what's the root cause of the exception?

are you able to re-index the workspace after such an event or is the
data in the persistence manager corrupt as well?

regards
 marcel

2010/2/2 Sergey Podatelev <brightnesslevels@gmail.com>:
> 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