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 <[email protected]>: > 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 >
