jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luca Tagliani (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCR-3299) Adding new index infos generation is not atomic
Date Sat, 30 Jun 2012 06:47:43 GMT

    [ https://issues.apache.org/jira/browse/JCR-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404412#comment-13404412
] 

Luca Tagliani edited comment on JCR-3299 at 6/30/12 6:46 AM:
-------------------------------------------------------------

With this code the indexes are rebuilt even if they are consistent.

I have this problem and using Luke 3.5.0 (http://code.google.com/p/luke/) I can open the indexes
and it seems they are consistent.

The real problem is that my index size is 6GB and the rebuild process takes about 5/6 hours.

So I was wondering if it's possible to rebuild only the indexes_xxxx file after checking the
indexes consistence with Lucene?

BR

Luca Tagliani
                
      was (Author: luca.tagliani):
    With this code the indexes are rebuilt even if they are consistent.

I have this problem and using Luke 3.5.0 (http://code.google.com/p/luke/) I can open the indexes
and it seems they are consistent.

So I was wondering if it's possible to rebuild only the indexes_xxxx file after checking the
indexes consistence with Lucene?

BR

Luca Tagliani
                  
> Adding new index infos generation is not atomic
> -----------------------------------------------
>
>                 Key: JCR-3299
>                 URL: https://issues.apache.org/jira/browse/JCR-3299
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.0, 2.1, 2.2, 2.4
>            Reporter: Marcel Reutegger
>            Priority: Minor
>             Fix For: 2.5
>
>
> Writing a new IndexInfos to disk is not atomic. It may happen that e.g. an empty indexes_xxxx
file is placed into the index directory when the JVM is killed. A subsequent startup will
then fail with a exception like this:
> Caused by: java.io.EOFException
> 	at java.io.DataInputStream.readInt(DataInputStream.java:375)
> 	at org.apache.jackrabbit.core.query.lucene.IndexInfos.read(IndexInfos.java:303)
> 	at org.apache.jackrabbit.core.query.lucene.IndexInfos.<init>(IndexInfos.java:107)
> 	at org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:253)
> 	at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:554)
> 	at
> org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:78)
> The lucene directory abstraction does not expose a method anymore to atomically rename
a file, which would probably be the preferred way to fix this. Instead I suggest we make the
initialization more resilient and catch these kind of cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message