java - Java7 "Solr/Lucene"bug有多严重？

Question

显然 Java7 在循环优化方面存在一些令人讨厌的错误:Google search .

从报告和错误描述中，我发现很难判断这个错误的严重程度(除非您使用 Solr 或 Lucene)。

我想知道的:

• 我的(任何)计划受到影响的可能性有多大？
• 错误的确定性是否足以让正常的测试发现它？

注意:我不能让我的程序的用户使用 -XX:-UseLoopPredicate 来避免这个问题。

Answer 1

任何热点错误的问题在于，您需要达到编译阈值(例如 10000)才能得到它:因此，如果您的单元测试“微不足道”，您可能无法捕捉到它。

例如，我们在 lucene 中发现了不正确的结果问题，因为这个特定的测试创建了 20,000 个文档索引。

在我们的测试中，我们随机化了不同的接口(interface)(例如不同的目录实现)和索引参数等，并且测试只有 1% 的时间失败，当然它可以用相同的随机种子重现。我们还在测试创建的每个索引上运行 checkindex，它会进行一些健全性测试以确保索引没有损坏。

对于我们找到的测试，如果您有特定的配置:例如RAMDirectory + PulsingCodec + 为该字段存储的有效负载，然后在达到编译阈值后，帖子上的枚举循环返回不正确的计算，在这种情况下，一个术语的返回文档数!= 为该术语存储的 docFreq。

我们有很多压力测试，重要的是要注意这个测试中的正常断言实际上通过了，它最后的 checkindex 部分失败了。

这样做的最大问题是，lucene 的增量索引基本上是通过将多个段合并为一个段来工作的:因此，如果这些枚举计算无效数据，那么这些无效数据会存储到新的合并索引:又名腐败。

我想说这个错误比我们之前遇到的循环优化器热点错误(例如，符号翻转的东西，https://issues.apache.org/jira/browse/LUCENE-2975)要狡猾得多。在那种情况下，我们得到了古怪的负面文档增量，这使得它很容易被捕获。我们也只需要手动展开一个方法来躲避它。另一方面，我们最初对此进行的唯一“测试”是 http://www.pangaea.de/ 的巨大 10GB 索引。 ，因此将其缩小到这个错误是很痛苦的。

在这种情况下，我花了很多时间(例如上周的每个晚上)尝试手动展开/内联各种东西，尝试创建一些解决方法，这样我们就可以避开错误并且不存在损坏索引的可能性创建的。我可以躲避一些情况，但还有很多情况我不能……而且我敢肯定，如果我们可以在测试中触发这些东西，还有更多的情况……