Marcel, I'm having troubles providing a reliable test-case for this, since in actual production environment this happens only about one time out of six, and the environment itself is a pretty complex one.
Can you perhaps give me some pointers on what might be a cause for this one except multi-threaded access or what could increase the probability of the error? My environment is a web application where jackrabbit is used as an application bundle, and it's configured for distributed transactions support along with mysql connector using Jencks. Like I said, the error happens when there're a lot of consecutive repository writes with calls to session.save() upon each write, however, they're all triggered by a single web request. On Mon, Feb 8, 2010 at 11:19 AM, Marcel Reutegger <[email protected]> wrote: > Hi, > > 2010/2/5 Sergey Podatelev <[email protected]>: >> Thanks for your reply, Marcel. >> >> On Thu, Feb 4, 2010 at 8:12 PM, Marcel Reutegger >> <[email protected]> wrote: >> >>> is that a single threaded environment or is it possible that multiple >>> threads share a session? that's not supported. >> >> The Session instance is only utilized by a single thread. >> >>> what's the root cause of the exception? >> >> Here goes, the silly-looking printouts are those that I put in >> SearchIndex myself: >> >> 2010-02-05 19:48:20,794 DEBUG observation.ObservationDispatcher - >> notifying 3 synchronous listeners. >> 2010-02-05 19:48:20,794 DEBUG core.SearchManager - onEvent: indexing started >> 2010-02-05 19:48:20,795 DEBUG lucene.SearchIndex - search index: >> updateNodes() >> 2010-02-05 19:48:20,796 DEBUG lucene.SearchIndex - trying to create document >> 2010-02-05 19:48:20,797 WARN lucene.SearchIndex - Exception while >> creating document for node: 4977b098-bba2-4274-ae7d-7575d2679526: >> javax.jcr.RepositoryException: Error while indexing node: >> 4977b098-bba2-4274-ae7d-7575d2679526 of type: >> {http://www.jcp.org/jcr/nt/1.0}unstructured: >> 4977b098-bba2-4274-ae7d-7575d2679526/{}date-updated: >> 4977b098-bba2-4274-ae7d-7575d2679526/{}date-updated >> >> 2010-02-05 19:48:20,798 DEBUG lucene.SearchIndex - whoopsy, failed!, >> root cause: org.apache.jackrabbit.core.state.NoSuchItemStateException: >> 4977b098-bba2-4274-ae7d-7575d2679526/{}date-updated > > that looks like a node indicates that there is a data-updated > property, but when trying to read the property it turns out it doesn't > exist. that's quite strange. usually such situations may occur when > multiple threads access the same session instance and modify content > concurrently. > > are you able to provide a test case that reproduces the issue? > > regards > marcel > >> 2010-02-05 19:48:20,798 DEBUG lucene.SearchIndex - trying to create document >> 2010-02-05 19:48:20,800 DEBUG core.SearchManager - onEvent: indexing >> finished in 6 ms. >> >>> are you able to re-index the workspace after such an event or is the >>> data in the persistence manager corrupt as well? >> >> If I just restart the app or the server, JackRabbit says the redo.log >> is empty, so there's nothing to re-index, thus the state of the >> indexes stays wrong, and I still get wrong query results. >> >> Removing the contents of $home$/index and >> $home$/workspaces/default/index directories and then restarting the >> server, restores proper index. >> >> -- >> sp >> > -- sp
