[jira] [Commented] (OAK-4939) Isolate corrupted index and make async indexer more resilient

["Vikas Saurabh (JIRA)" <ji...@apache.org>]

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

Vikas Saurabh commented on OAK-4939:
------------------------------------

bq. IndexUpdate while making call to editor looks for any exception thrown. In case of any exception received for any specific editor it would set corrupted to true for that index definition and let that indexing cycle fail

A very small number of cases that I've seen for this happen at the time of merging the changes at the end. So, while at the risk of tying an implementation detail, I think it might be a good hint to look at what causes a merge exception (if that's the case) to figure out the editor to be mark corrupted.
On second thoughts, how about a different builder to apply their changes for each editor? Basically, each editor to get a fork of head' but diff happens on head v/s base while calling back to each editor for changes.

> Isolate corrupted index and make async indexer more resilient
> -------------------------------------------------------------
>
>                 Key: OAK-4939
>                 URL: https://issues.apache.org/jira/browse/OAK-4939
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: lucene, query
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>             Fix For: 1.6
>
>
> Currently if any one of the async index gets corrupted it brings down the whole async indexer and no other index gets updated untill system administrator reindexes the problamatic async index. 
> Instead of fail all we should isolate such corrupted index and mark them as corrupted. And still let async indexer progress for other working indexes. 
> This would ensure that one corrupted index does not affect the whole system and allow the application to work partially. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)