You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Luca Tagliani (JIRA)" <ji...@apache.org> on 2012/06/30 08:47:43 UTC
[jira] [Comment Edited] (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=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