Сбои JVM в Lucene DataInput.readVInt - PullRequest
       28

Сбои JVM в Lucene DataInput.readVInt

1 голос
/ 22 ноября 2011

Моя JVM (1.6.0_29) постоянно падает при интенсивном использовании при индексации документов с помощью Lucene.Я получаю:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002b6b196d767c, pid=26417, tid=1183217984
#
# JRE version: 6.0_29-b11
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J  org.apache.lucene.store.DataInput.readVInt()I
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Среда:

JDK: 1.6u29 (та же проблема с 1.6_02) Lucene Версия 3.4.0

vm_info: Java HotSpot (TM) 64Серверная виртуальная машина (20.4-b02) для linux-amd64 JRE (1.6.0_29-b11), построена 3 октября 2011 г. 01:19:20 с помощью java_re с gcc 3.2.2 (SuSE Linux)

ОС: CentOS выпуск 5.0 (финальный)

jvm_args: -Dcatalina.home = / var / local / tomcat-8081 -Dcatalina.base = / var / local / tomcat-8081 -Djava.io.tmpdir =/ var / tmp -Dfile.encoding = UTF-8 -Xmx1024M -XX: MaxPermSize = 96m

Кажется, это проблема jdk, которая была исправлена ​​в jdk 1.7, но другие проблемы, где были представлены.https://issues.apache.org/jira/browse/LUCENE-3335 "Java 7 содержит исправление проблемы readVInt начиная с 1.6.0_21 (приблизительно, LUCENE-2975)"

Итак, как я могу исправить эту проблему с помощью JDK 1.6?Должен ли я обновить до JDK 1,7?

Ответы [ 2 ]

4 голосов
/ 22 ноября 2011

эти проблемы JDK также исправлены в 1.6.9_29 (не только 1.7.0u1).ReadVInt больше не может аварийно завершить работу.Таким образом, ваш сбой не связан ни с одной из «известных ошибок java6 / 7» (ошибка vint вообще не приводит к сбою вашей JVM, она просто повреждает ваш индекс, возвращая неправильные значения - и эта ошибка определенно исправлена ​​с Lucene 3.1).

Но есть еще один шанс, что вы можете разбить JVM: вы работаете на 64-битной платформе (Linux), поэтому реализация каталога по умолчанию - MMapDirectory.Lucene использует хак, чтобы иметь возможность отображать сопоставленные файлы из виртуального адресного пространства.Это не разрешено самой JVM, но делает удаление карт зависимым от сборщика мусора, что является проблемой для Lucene.По умолчанию MMapDirectory отображает файлы после закрытия IndexInputs.MMapDirectory вообще не синхронизируется, поэтому, когда другой поток пытается получить доступ к IndexInput после отмены сопоставления, он получит доступ к несопоставленному адресу и будет SIGSEGV.

Если ваш код будет правильным, этого не произойдет, но похоже, что выиспользование уже закрытого IndexReader / IndexWriter для доступа к индексу.До Lucene 3.5 (скоро выйдет), пропущенные проверки в IndexReader сделают возможным, чтобы уже закрытый IndexReader со всеми его закрытыми (и не отображенными) IndexInputs попытался получить доступ к данным индекса и ошибкам сегмента.

В 3.5 мы добавилидополнительные проверки безопасности, чтобы предотвратить этот незаконный доступ, но это не 100% (так как синхронизация отсутствует).Я бы пересмотрел код и проверил, что ничто не обращается к закрытому индексу.

Простая проверка, чтобы убедиться, что это ваша проблема, состоит в том, чтобы использовать NIOFSDirectory (медленнее в Linux) вместо MMapDirectory.Если это не приводит к сбою и, возможно, выдает AlreadyClosedExceptions, ошибка заключается в доступе к закрытым индексам.

0 голосов
/ 22 ноября 2011

В соответствии с этой статьей следующие причины могут быть вызваны и в Java 6:

Обратите внимание: это также влияет на пользователей Java 6, если они используют одну из этих JVM.параметры, которые не включены по умолчанию: -XX: + OptimizeStringConcat или -XX: + AggressiveOpts

Используете ли вы какие-либо из них?

...