Повреждение индекса Lucene?
Мы используем поиск в спящем режиме (5.6.5.Final) + lucene (5.5.5) и замечаем периодические проблемы на некоторых из наших серверов при запросе индекса.
Я не уверен на 100%, какую информацию мне нужно было бы предоставить, чтобы попытаться сузить проблему, но мы видим следы стека в журналах, например:
java.lang.ArrayIndexOutOfBoundsException
at org.apache.lucene.store.ByteArrayDataInput.readVInt(ByteArrayDataInput.java:105)
at org.apache.lucene.codecs.blocktree.IntersectTermsEnumFrame.nextNonLeaf(IntersectTermsEnumFrame.java:254)
at org.apache.lucene.codecs.blocktree.IntersectTermsEnumFrame.next(IntersectTermsEnumFrame.java:239)
at org.apache.lucene.codecs.blocktree.IntersectTermsEnum.popPushNext(IntersectTermsEnum.java:345)
at org.apache.lucene.codecs.blocktree.IntersectTermsEnum._next(IntersectTermsEnum.java:713)
at org.apache.lucene.codecs.blocktree.IntersectTermsEnum.next(IntersectTermsEnum.java:501)
at org.apache.lucene.index.FilteredTermsEnum.next(FilteredTermsEnum.java:224)
at org.apache.lucene.search.FuzzyTermsEnum.next(FuzzyTermsEnum.java:240)
at org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:67)
at org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
at org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:331)
at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:278)
at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:278)
at org.hibernate.search.query.engine.impl.LazyQueryState.rewrittenQuery(LazyQueryState.java:192)
at org.hibernate.search.query.engine.impl.LazyQueryState.search(LazyQueryState.java:103)
at org.hibernate.search.query.engine.impl.QueryHits.updateTopDocs(QueryHits.java:241)
at org.hibernate.search.query.engine.impl.QueryHits.<init>(QueryHits.java:136)
at org.hibernate.search.query.engine.impl.LuceneHSQuery.getQueryHits(LuceneHSQuery.java:360)
at org.hibernate.search.query.engine.impl.LuceneHSQuery.queryEntityInfos(LuceneHSQuery.java:145)
at org.hibernate.search.query.hibernate.impl.FullTextQueryImpl.list(FullTextQueryImpl.java:197)
at org.hibernate.search.jpa.impl.FullTextQueryImpl.getResultList(FullTextQueryImpl.java:157)
Трассировки стека не всегда одинаковы (вместо readVInt они могут быть в readVLong), но исключением всегда является ArrayIndexOutOfBoundsException.
Когда я запустил инструмент проверки индекса (org.apache.lucene.index.CheckIndex) с индексом, полученным с сервера, он не сообщил об ошибках:
Segments file=segments_2 numSegments=1 version=5.5.5 id=e963cq35m2ov726h5wwj8aw39 format=
1 of 1: name=_1t maxDoc=300616
version=5.5.5
id=e963cq35m2ov726h5wwj8aw38
codec=Lucene54
compound=false
numFiles=10
size (MB)=45.838
diagnostics = {os=Linux, java.vendor=Oracle Corporation, java.version=1.8.0_141, java.vm.version=25.141-b16, lucene.version=5.5.5, mergeMaxNumSegments=1, os.arch=amd64, java.runtime.version=1.8.0_141-b16, source=merge, mergeFactor=5, os.version=2.6.32-696.3.2.el6.x86_64, timestamp=1533021441077}
no deletions
test: open reader.........OK [took 1.027 sec]
test: check integrity.....OK [took 0.040 sec]
test: check live docs.....OK [took 0.000 sec]
test: field infos.........OK [9 fields] [took 0.000 sec]
test: field norms.........OK [7 fields] [took 0.041 sec]
test: terms, freq, prox...OK [1231930 terms; 16245644 terms/docs pairs; 16300635 tokens] [took 1.719 sec]
test: stored fields.......OK [601232 total field count; avg 2.0 fields per doc] [took 0.215 sec]
test: term vectors........OK [0 total term vector count; avg 0.0 term/freq vector fields per doc] [took 0.000 sec]
test: docvalues...........OK [0 docvalues fields; 0 BINARY; 0 NUMERIC; 0 SORTED; 0 SORTED_NUMERIC; 0 SORTED_SET] [took 0.000 sec]
No problems were detected with this index.
Мы перестраиваем индекс на главном узле, а затем копируем его на подчиненные. Я думаю, что это может быть проблема с коррупцией при копировании, но я думаю, что программа проверки сообщит о подобных проблемах. Есть идеи, что я могу сделать, чтобы сузить эту проблему?
Мы используем провайдер каталога FSSlaveDirectoryProvider и серверную часть JMS для внесения изменений.
Хорошо, на данный момент это либо проблема конфигурации, либо ошибка. Предоставьте список всех установленных вами свойств Hibernate Search и их значений как на главном, так и на подчиненных устройствах. Также подтвердите, что вы не изменяете индекс ни через собственные API Lucene, ни через доступ к файловой системе.
Я не уверен, можно ли это квалифицировать как вмешательство, поскольку у нас обычно никогда не возникает проблем с ним, и он работает без проблем в течение довольно долгого времени, но мы регулярно перестраиваем индекс (в последнее время с каждой недели до каждой ночи ). Задание выполняется на главном узле: 1. Остановите фоновый процесс, в котором запущен приемник JMS. 2. Запустите массовый индексатор (указанный в отдельном каталоге) и скопируйте полученный индекс после его выполнения в локальный главный индекс. 3. Перезапустите прослушиватель JMS.
Хотя кажется, что мы переопределяем стратегию чтения по умолчанию (SharingBufferReaderProvider), поскольку в прошлом у нас были проблемы с этим процессом. Судя по прошлой заявке, мы получали «java.lang.IllegalStateException: тот же сегмент _a имеет недопустимые изменения; вероятно, вы повторно открываете программу чтения после незаконного удаления файлов индекса самостоятельно и создания нового индекса вместо них». Переопределенный считыватель просто улавливает ошибку и закрывает считыватель, а затем снова открывает их. Мы перестраивали индекс с этим «исправлением» в течение некоторого времени и на самом деле не обнаружили никаких проблем с ним.
Как вы копируете индекс? Вам действительно не следует пытаться изменить состояние индекса, не зная, что вы делаете. Вы используете подходящий
filsystem-master/filesystem-slaveпровайдеры каталогов? Вы также используете один из встроенные бэкэнды или просто не выполняете никаких изменений базы данных на ведомых устройствах?