Hi, On Sat, Feb 13, 2010 at 16:41, Sergey Podatelev <[email protected]> wrote: > 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.
hmm, maybe this is related to the distributed transaction... does it also happen when you are *not* using XA? regards marcel > 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 >
