jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3299) Adding new index infos generation is not atomic
Date Mon, 02 Jul 2012 10:48:22 GMT

    [ 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

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


View raw message