jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Created] (OAK-3629) Index corruption seen with CopyOnRead when index defnition is recreated
Date Fri, 13 Nov 2015 09:57:11 GMT
Chetan Mehrotra created OAK-3629:

             Summary: Index corruption seen with CopyOnRead when index defnition is recreated
                 Key: OAK-3629
                 URL: https://issues.apache.org/jira/browse/OAK-3629
             Project: Jackrabbit Oak
          Issue Type: Bug
          Components: lucene
            Reporter: Chetan Mehrotra
            Assignee: Chetan Mehrotra
            Priority: Minor
             Fix For: 1.3.11, 1.0.24, 1.2.9

CopyOnRead logic relies on {{reindexCount}} to determine the name of directory in which index
files would be copied. In normal flow if the index is reindexed then this count would get
increased and newer index files would get copied to a new directory.

However if the index definition node gets recreated due to some deployment process then this
count gets reset to 0. Due to which newly created index files from reindexing would start
getting copied to already existing directory and that can lead to corruption.

Note that here corruption is transient i.e. persisted index is not corrupted. Just that locally
copied index gets corrupted. Cleaning up the index directory would fix the issue and that
can be used as a workaround.


After discussing with [~tmueller] following approach can be used.

Instead of relying on reindex count we can maintain a hidden randomly generated uuid and store
it in the index config. This would be used to derive the name of directory on filesystem.
If the index definition gets reset then the uuid can be regenerated. 

This message was sent by Atlassian JIRA

View raw message