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

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

Some inspection of all the metrics captured indicates that the method [1] is 
the main cause of differences in times taken to open, sync and close the 
directory index, as each operation must generate a fresh SHA1 from all the 
index files. 

If it was possible to rely on some other mechanism for checking the integrity 
of each file, this checksum could be replaced with something much simpler, like 
file length which would avoid generating a sha1 on each operation. This would 
then rely on Oak Lucene managing the recovery rather than the Oak Directory 
listing being self healing. To achieve this, a drop() method on the 
OakDirectory might be required to drop the current generation of the listing on 
demand.


1 
https://github.com/apache/jackrabbit-oak/compare/trunk...ieb:OAK-3547#diff-28ec89220db72ab858b9eb25927c2a29R1026

> 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