jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Podatelev <brightnesslev...@gmail.com>
Subject Re: Index corruption
Date Sat, 13 Feb 2010 15:41:14 GMT
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
<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