You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2012/07/02 12:48:22 UTC

[jira] [Commented] (JCR-3299) Adding new index infos generation is not atomic

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

Marcel Reutegger commented on JCR-3299:
---------------------------------------

Checking the consistency of the lucene index (not just on the lucene level, but also WRT Jackrabbit) requires a complete traversal of the content tree, which is more or less equivalent to the rebuilt.

What is the exact use/test case you have?
                
> 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