solr和lucene_Java 7导致Lucene和Solr用户头痛

solr和lucene

Java 7终于来了； 但是此版本并非毫无争议！ 发布后不久，Apache Lucene提交者Uwe Schindler 发出警告 ，指出Java 7包含热点编译器优化，可能会错误编译某些循环。 他警告说，此错误可能会影响“几个” Apache项目的代码-但目前，已知它会影响Lucene Core和Apache Solr的所有发行版本。 该错误不仅限于Java 7用户：如果Java 6用户使用默认情况下未启用的JVM选项之一，则还会警告该问题可能影响他们：

-XX：+ OptimizeStringConcat或
-XX：+ AggressiveOpts

这些错误是在Java 7发布前五天发现的，关于Oracle是否有时间修复这些错误一直存在争议。 在他的博客中， Uwe Schindler质疑在预览版和Java 7的最终版本之间缺少进入代码的更新。他指出，用户可以验证最终JDK版本与6月27日的预览版本相同。 ，方法是检查Windows Installer EXE文件签名的时间戳。

“因此，Oracle忽略了预览版中的所有错误（不仅是我们的错误），只是发布了一个月大的软件包！ 那么预览发布的意义是什么？ 他们可以在一个月前发布它！ 肯定不是要进行公开审查和寻找错误！” 他说。

但是，其他人则认为，发现问题的时间与发布日期相距太近，因此Oracle无法解决该问题：

“这些问题仅在Java 7正式发布前5天被发现，因此Oracle没有时间修复这些错误，” Oracle ACE总监Markus Eisele说道，他还辩称“源代码是开放的，因此任何顽固的人都可以挖掘可以解决问题。”

问题的严重性也引起了辩论。 Elvis的Core Java和Enterprise Java的作者Cay Horstmann表示，尽管他不担心可能导致崩溃的Hotspot问题，但他担心Java 7会无声地产生错误的结果。 他说：“我尽量避免对这些事情感到恐惧，但是我必须说，广泛使用的平台中“很少发生的”错误困扰着我。 “罕见的崩溃是可以管理的，但默默地获取错误的结果却并非如此。 我本以为这是一个高优先级的错误。”

“ Java 7 Solr / Lucene错误有多严重 ？” 目前还正在就stackoverflow进行辩论，这导致Lucene的提交者Robert Muir发表了对此事的想法：

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

在这种情况下，我花费了大量时间（例如，上周的每个晚上）尝试手动展开/内联各种操作，而不是尝试创建一些解决方法，以便我们避开该错误并可能创建损坏的索引。 我可以避开某些情况，但是还有更多我无法解决的情况...我敢肯定，如果我们能够在测试中触发这些东西，那还会有更多的情况……”

同时，Markus Eisele指出，问题通常与Java 7无关，而与HotSpot JVM有关。 他还向开发人员保证，问题仅限于大量使用破坏了优化方法的软件，并且“对于一般用例，这不会影响您。”

已经提交了一个Oracle Bug，该Oracle Bug现在已从“低”优先级升级到“高”优先级，并且认为该问题将在Update Pack 1中得到解决。

翻译自: https://jaxenter.com/java-7-causes-headaches-for-lucene-and-solr-users-103655.html

solr和lucene