[
https://issues.apache.org/jira/browse/OAK-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15581189#comment-15581189
]
Chetan Mehrotra edited comment on OAK-4939 at 10/17/16 4:43 AM:
----------------------------------------------------------------
One way to implement this
# {{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
# Upon next cycle run it would ignore such corrupted indexes and only work with
editor instance for working indexes.
# However it would log a warning for such corrupted index mentioning that
system admin should reindex.
# In addition the IndexStatsMBean would also expose such corrupted index so
monitoring system can look for that and issue required alerts
# Upon reindexing the {{IndexUpdate}} would clear the {{corrupted}} flag
# Async indexer MBean would have a new operation which allows system admin to
do an indexing run which include such corrupted index to re check what is the
failure cause
Such an approach would ensure that even if one of the index gets corrupted the
asyn index continue to work fine for other indexes. So only queries which make
use of such corrupted index would suffer instead of the whole application. This
would be specially useful for system where an index is being created per tenant
[~alexparvulescu] [~catholicon] [~tmueller] Thoughts?
was (Author: chetanm):
One way to implement this
# {{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
# Upon next cycle run it would ignore such corrupted indexes and only work with
editor instance for working indexes.
# However it would log a warning for such corrupted index mentioning that
system admin should reindex.
# In addition the IndexStatsMBean would also expose such corrupted index so
monitoring system can look for that and issue required alerts
# Upon reindexing the {{IndexUpdate}} would clear the {{corrupted}} flag
Such an approach would ensure that even if one of the index gets corrupted the
asyn index continue to work fine for other indexes. So only queries which make
use of such corrupted index would suffer instead of the whole application. This
would be specially useful for system where an index is being created per tenant
[~alexparvulescu] [~catholicon] [~tmueller] Thoughts?
> 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)
