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] [Commented] (JCR-3299) Adding new index infos generation is not atomic
Date Mon, 02 Jul 2012 13:09:22 GMT

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

Luca Tagliani commented on JCR-3299:

Last week a customer server (a VMWare machine) suffer a failure on the disk on which is stored
the machine itself and the JVM is terminated abruptly.
When the server come up, the indexes_xxxx file is empty, and I found that also two subfolder
of the index folder contains file of 0 byte.
The size of the workspace index is about 8 GB, so the rebuild process (even disabling full-text
indexing) took about 6/7 hours.
For my customer this is not acceptable, so I was wondering if there was an alternate method
to correct the indexes without rebuilding them completely.

> 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