Проблема с любыми ошибками в горячих точках заключается в том, что вам нужно достичь порога компиляции (например, 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/,, поэтому было больно сужать его до этой ошибки.
В этом случае япотратил много времени (например, каждую ночь на прошлой неделе), пытаясь вручную развернуть / встроить различные вещи, пытаясь найти обходной путь, чтобы мы могли избежать ошибки и не иметь возможности создания поврежденных индексов.Я мог бы уклониться от некоторых случаев, но было гораздо больше случаев, которые я не мог ... и я уверен, что если мы сможем запустить этот материал в наших тестах, есть еще случаи ...