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 Mon, 15 Feb 2010 12:41:54 GMT
Hi,

On Sat, Feb 13, 2010 at 16:41, Sergey Podatelev
<brightnesslevels@gmail.com> 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
> <marcel.reutegger@gmx.net> wrote:
>> Hi,
>>
>> 2010/2/5 Sergey Podatelev <brightnesslevels@gmail.com>:
>>> Thanks for your reply, Marcel.
>>>
>>> On Thu, Feb 4, 2010 at 8:12 PM, Marcel Reutegger
>>> <marcel.reutegger@gmx.net> 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
>

Mime
View raw message