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

Ian Boston commented on OAK-3547:
---------------------------------

The original patch was written such a long time ago, I don't think IndexCopier 
was present, or at least the deployment the patch was targeting did not have 
writeOnCopy etc enabled or possibly available. The impl of OakIndexFile is 
suboptimal for Lucene usage, as it loads chunks of the index into memory as 
byte[] to perform seek, whereas FSDirectory uses OS level native code to seek, 
hence it makes no sense to use OakDirectory any more. FSDirectory should be 
used by whatever means necessary. Might be an idea to delete or deprecate 
OakDirectory, so its not used for opening lucene indexes.

The patch is in a state where it should not be applied or used. It can't 
efficiently determine corruption without direct access to the underlying file, 
which is abstracted by Oak.

With the benefit of hindsight, the patch should be in IndexCopier to prevent a 
bad segments.gen file failing the index.

We should close this issue as the patch isn't valid any more.


> 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
>             Fix For: 1.6
>
>
> 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)

Reply via email to