[
https://issues.apache.org/jira/browse/OAK-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14989600#comment-14989600
]
Ian Boston commented on OAK-3547:
---------------------------------
[~mreutegg] Currently every call to OakDirectory.sync(...) and
OakDirectory.close(...) where the OakDirectory is not a read only oak
directory, causes a list of files with size and sha1 hash to be written to a
new node with a name of the form /oak:index/<lucene index>/:state/l_<epoch>.
When the current Oak session commits, that is committed to the Oak repo. When
the OakDirectory is loaded, it tries upto 100 l_<epoch> nodes in order, newest
first, checking that the contents are present and have matching length+sha1.
The first valid listing found is loaded. If no valid matches are found then the
code reverts to earlier behaviour, using all the non deleted files in the
/oak:index/<lucene index>/:dir folder. If the bundle is deployed to an existing
repository it will fall back to the old behaviour.
I have assumed a call to either OakDirectory.sync(...) or
OakDirectory.close(...) indicates a checkpoint of the Lucene indexing process.
> Improve ability of the OakDirectory to recover from unexpected file errors
> --------------------------------------------------------------------------
>
> Key: OAK-3547
> URL: https://issues.apache.org/jira/browse/OAK-3547
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
> Affects Versions: 1.4
> Reporter: Ian Boston
>
> Currently if the OakDirectory finds that a file is missing or in some way
> damaged, and exception is thrown which impacts all queries using that index,
> at times making the index unavailable. This improvement aims to make the
> OakDirectory recover to a previously ok state by storing which files were
> involved in previous states, and giving the code some way of checking if they
> are valid.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
