Насколько серьезна ошибка Java7 "Solr/Lucene"?

Очевидно, Java7 имеет некоторые неприятные ошибки в отношении оптимизации цикла: поиск Google.

Из отчетов и описаний ошибок мне трудно судить о том, насколько значительна эта ошибка (если вы не используете Solr или Lucene).

Что я хотел бы знать:

Насколько вероятна моя (любая) программа?
Является ли ошибка достаточно детерминированной, чтобы нормальное тестирование могло ее уловить?

Примечание. Я не могу заставить пользователей использовать мою программу -XX:-UseLoopPredicate, чтобы избежать проблемы.

Ответ 1

Проблема с любыми ошибками хот-спота заключается в том, что вам нужно достичь порога компиляции (например, 10000), прежде чем он сможет вас достать: поэтому, если ваши модульные тесты "тривиальны", вы, вероятно, не поймаете его.

Например, мы обнаружили ошибку с неправильными результатами в lucene, потому что этот конкретный тест создает 20 000 индексов документа.

В наших тестах мы рандомизируем разные интерфейсы (например, разные реализации Справочника) и параметры индексирования и т.д., и тест только терпит неудачу 1% времени, конечно, его затем воспроизводятся с одним и тем же случайным семенем. Мы также запускаем checkindex для каждого индекса, который создает тесты, которые выполняют некоторые тесты на здравомыслие, чтобы гарантировать, что индекс не поврежден.

Для теста мы обнаружили, что если у вас есть определенная конфигурация: например, RAMDirectory + PulsingCodec +, хранящиеся для этого поля, после того как он достиг порога компиляции, цикл перечисления над проводками возвращает неверные вычисления, в этом случае количество возвращаемых документов для терма!= DocFreq, сохраненное для этого термина.

У нас есть большое количество стресс-тестов, и важно отметить, что нормальные утверждения в этом тесте фактически проходят, его часть checkindex в конце, которая терпит неудачу.

Большая проблема заключается в том, что инкрементная индексация lucene в основном работает путем слияния нескольких сегментов в один: из-за этого, если эти перечисления вычисляют недействительные данные, эти недопустимые данные затем сохраняются в вновь объединенном индексе: aka коррупция.

Я бы сказал, что эта ошибка намного сложнее, чем предыдущие ошибки хот-спота оптимизатора цикла, которые мы нажимаем (например, текст с надписью, https://issues.apache.org/jira/browse/LUCENE-2975). В этом случае мы получили дурацкие негативные дельта-документы, которые позволяют легко поймать. Мы также должны были вручную развернуть один метод, чтобы уклониться от него. С другой стороны, единственным "тестом", который мы изначально для этого были, был огромный индекс в 10 ГБ http://www.pangaea.de/, поэтому было больно сузить это к этой ошибке.

В этом случае я потратил много времени (например, каждую ночь на прошлой неделе), пытаясь вручную развернуть/вставить различные вещи, пытаясь создать некоторое обходное решение, чтобы мы могли уклониться от ошибки и не иметь возможности коррумпированных индексов быть создано. Я мог уклониться от некоторых случаев, но было еще много дел, которые я не мог... и я уверен, что если мы сможем запустить этот материал в наших тестах, там будет больше случаев...

Ответ 2

Простой способ воспроизвести ошибку. Откройте eclipse (Indigo в моем случае) и перейдите в раздел Справка/Поиск. Введите строку поиска, вы заметите, что сбой eclipse. Посмотрите на журнал.

# Problematic frame:
# J  org.apache.lucene.analysis.PorterStemmer.stem([CII)Z
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x0000000007b79000):  JavaThread "Worker-46" [_thread_in_Java, id=264, stack(0x000000000f380000,0x000000000f480000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000002f62bd80e

Registers:

Ответ 3

Проблема, по-прежнему существует на 2 декабря 2012 г. в Oracle JDK java -version java-версия "1.7.0_09" Java (TM) SE Runtime Environment (сборка 1.7.0_09-b05) Java HotSpot (TM) 64-разрядная серверная VM (сборка 23.5-b02, смешанный режим) и openjdk java-версия "1.7.0_09-icedtea" Рабочая среда OpenJDK (fedora-2.3.3.fc17.1-x86_64) 64-разрядная серверная версия OpenJDK (сборка 23.2-b09, смешанный режим)

Странно, что индивидуально любой из -XX: -UseLoopPredicate или -XX: LoopUnrollLimit = 1 опция предотвращает ошибку, но при использовании вместе - JDK не работает см., например, https://bugzilla.redhat.com/show_bug.cgi?id=849279

Ответ 4

Хорошо, два года спустя, и я считаю, что эта ошибка (или ее вариация) все еще присутствует в версии 1.7.0_25-b15 на OSX.

Через очень болезненное испытание и ошибку я решил, что использование Java 1.7 с Solr 3.6.2 и autocommit <maxTime>30000</maxTime>, по-видимому, вызывает повреждение индекса. Похоже, что это произойдет с w/1.7 и maxTime при 30000, если я переключусь на Java 1.6, у меня нет проблем. Если я опустил maxTime до 3000, у меня проблем нет.

JVM не сбой, но он заставляет RSolr умереть со следующей трассировкой стека в Ruby: https://gist.github.com/armhold/6354416. Он делает это надежно после сохранения нескольких сотен записей.

Учитывая, что здесь задействовано много слоев (Ruby, Sunspot, Rsolr и т.д.), я не уверен, что могу сварить это во что-то, что окончательно доказывает ошибку JVM, но он уверен, что это происходит здесь. FWIW Я также попробовал JDK 1.7.0_04, и это также проявляет проблему.

Ответ 5

Как я понимаю, эта ошибка встречается только на сервере jvm. Если вы запускаете свою программу на jvm-клиенте, вы в явном виде. Если вы запускаете свою программу на сервере jvm, это зависит от программы, насколько серьезной может быть проблема.