[ https://issues.apache.org/jira/browse/OAK-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614020#comment-15614020 ]
Abhishek Sharma edited comment on OAK-4114 at 10/28/16 2:14 AM: ---------------------------------------------------------------- Is there any update on this issue. The lucene index for AEM 6.1 Oak repository is corrupted on restart at times which takes significant time to build. was (Author: aurorabhi): Is there any update on this issue. The lucene index for AEM 6.1 Oak repository is corrupted on restart at times which takes gignificant time to build. > Cached lucene index gets corrupted in case of unclean shutdown and journal > rollback in SegmentNodeStore > ------------------------------------------------------------------------------------------------------- > > Key: OAK-4114 > URL: https://issues.apache.org/jira/browse/OAK-4114 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra > Priority: Minor > Labels: resilience > Fix For: 1.6 > > > Currently Oak Lucene support would copy index files to local file system as > part of CopyOnRead feature. In one of the setup it has been observed that > index logic was failing with following error > {noformat} > 04.02.2016 17:47:52.391 *WARN* [oak-lucene-3] > org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier > [/oak:index/lucene] Found local copy for _2ala.cfs in > MMapDirectory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1 > > lockFactory=NativeFSLockFactory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1 > but size of local 9320 differs from remote 3714150. Content would be read > from remote file only > 04.02.2016 17:47:52.399 *WARN* [oak-lucene-3] > org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopier > [/oak:index/lucene] Found local copy for segments_28je in > MMapDirectory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1 > > lockFactory=NativeFSLockFactory@/mnt/crx/author/crx-quickstart/repository/index/e5a943cdec3000bd8ce54924fd2070ab5d1d35b9ecf530963a3583d43bf28293/1 > but size of local 1214 differs from remote 1175. Content would be read from > remote file only > 04.02.2016 17:47:52.491 *ERROR* [oak-lucene-3] > org.apache.jackrabbit.oak.plugins.index.lucene.IndexTracker Failed to open > Lucene index at /oak:index/lucene > org.apache.lucene.index.CorruptIndexException: codec header mismatch: actual > header=1953790076 vs expected header=1071082519 (resource: > SlicedIndexInput(SlicedIndexInput(_2ala.fnm in _2ala.cfs) in _2ala.cfs > slice=8810:9320)) > at org.apache.lucene.codecs.CodecUtil.checkHeader(CodecUtil.java:128) > at > org.apache.lucene.codecs.lucene46.Lucene46FieldInfosReader.read(Lucene46FieldInfosReader.java:56) > at > org.apache.lucene.index.SegmentReader.readFieldInfos(SegmentReader.java:215) > {noformat} > Here size of __2ala.cfs_ differed from remote copy and possible other index > file may have same size but different content. Comparing the modified time of > the files with those in Oak it can be seen that one of file system was older > than one in Oak > {noformat} > _2alr.cfs={name=_2alr.cfs, size=1152402, sizeStr=1.2 MB, modified=Thu Feb 04 > 17:52:31 GMT 2016, osModified=Feb 4 17:52, osSize=1152402, mismatch=false} > _2ala.cfe={name=_2ala.cfe, size=224, sizeStr=224 B, modified=Thu Feb 04 > 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=224, mismatch=false} > _2ala.si={name=_2ala.si, size=252, sizeStr=252 B, modified=Thu Feb 04 > 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=252, mismatch=false} > _2ala.cfs={name=_2ala.cfs, size=3714150, sizeStr=3.7 MB, modified=Thu Feb 04 > 17:47:28 GMT 2016, osModified=Feb 4 17:17, osSize=9320, mismatch=true} > _14u3_29.del={name=_14u3_29.del, size=1244036, sizeStr=1.2 MB, modified=Thu > Feb 04 16:37:35 GMT 2016, osModified=Feb 4 16:37, osSize=1244036, > mismatch=false} > _2akw.si={name=_2akw.si, size=252, sizeStr=252 B, modified=Thu Feb 04 > 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=252, mismatch=false} > _2akw.cfe={name=_2akw.cfe, size=224, sizeStr=224 B, modified=Thu Feb 04 > 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=224, mismatch=false} > _2akw.cfs={name=_2akw.cfs, size=4952761, sizeStr=5.0 MB, modified=Thu Feb 04 > 16:37:07 GMT 2016, osModified=Feb 4 16:37, osSize=4952761, mismatch=false} > {noformat} > And on same setup the system did saw a rollback in segment node store > {noformat} > -rw-rw-r--. 1 crx crx 25961984 Feb 4 16:47 data01357a.tar > -rw-rw-r--. 1 crx crx 24385536 Feb 4 16:41 data01357a.tar.bak > -rw-rw-r--. 1 crx crx 359936 Feb 4 17:18 data01358a.tar > -rw-rw-r--. 1 crx crx 345088 Feb 4 17:17 data01358a.tar.bak > -rw-rw-r--. 1 crx crx 70582272 Feb 4 18:35 data01359a.tar > -rw-rw-r--. 1 crx crx 66359296 Feb 4 18:33 data01359a.tar.bak > -rw-rw-r--. 1 crx crx 282112 Feb 4 18:46 data01360a.tar > -rw-rw-r--. 1 crx crx 236544 Feb 4 18:45 data01360a.tar.bak > -rw-rw-r--. 1 crx crx 138240 Feb 4 18:56 data01361a.tar > {noformat} > So one possible cause is that > # At some time earlier to 17:17 lucene index got updated and __2ala.cfs_ got > created. > # Post update the head revision in Segment store was updated but the revision > yet to made it to journal log > # Lucene CopyOnRead logic got event for the change and copied the file > # System crashed and hence journal did not got updated > # System restarted and per last entry in journal system suffered with some > "data loss" and hence index checkpoint also moved back > # As checkpoint got reverted index started at earlier state and hence created > a file with same name __2ala.cfs_ > # CopyOnRead detected file length change and logged a warning routing call to > remote > # However other files like _2ala.si, _2ala.cfe which were created in same > commit had same size but likely different content which later cause lucene > query to start failing > In such a case a restart after cleaning the existing index content would have > brought back the system to normal state. > So as a fix we would need to come up with some sanity check at time of system > startup -- This message was sent by Atlassian JIRA (v6.3.4#6332)