関口宏司のLuceneブログ

LuceneのConcurrentMergeSchedulerのデッドロック問題（あくまでも可能性であり、アプリケーションでへんなことをしていなければ大丈夫）が、JIRAにチケット管理されないまま修正されたので、メモしておく。

メールスレッド
修正(4.0)
修正(3.6)

ところで、このメールスレッドの中で紹介されていた「Java Puzzle」のサイトが手軽にできてよかったので簡単に紹介したい。

Wouter Coekaerts - Java Puzzle 1: Clowns

私は問題文（制限事項）をよく読まずに1秒でできたと思ったらちょっと違っていた。ヒントはVolkswagenのadd()メソッドがsynchronizedになっているところに注目する・・・という感じだろうか。

Java Puzzleは現在3つまで公開されている。



あの米Clouderaディレクターも参加したロンウイットのSolrトレーニング・・・受講者インタビュー記事
決算期の今は実は受講の大チャンス！あなたの部署の余った予算を有効活用しましょう。予算が余っていないか、上司に聞いてみましょう。        Solr 3.5 4月 トレーニング受講者募集中

先日お知らせしたJava 7の不具合が改修され、Lucene/Solrの動作確認が取れたため、アナウンスメールが流された。ロンウイットのホームページにも掲載したが、前回同様、こちらにも拙訳を掲載する。

Apache Lucene CoreおよびApache Solrユーザーの皆様こんにちは

オラクルは10月19日にJava 7u1 [1]をリリースしました。リリースノートおよびLuceneコミッターによるテスト結果から、7月28日に報告されたすべての不具合は本リリースにより改修されたことを確認しました。したがいまして、Porter StemmerはSIGSEGVによるクラッシュを発生させなくなりました。また、インデックス破壊も検出されませんので、Lucene CoreおよびSolrをJava 7u1上で安全に実行可能です。

同日、オラクルはJava 6u29[2]もリリースしました。Java 6において-XX:+AggressiveOptsまたは-XX:+OptimizeStringConcatのJVMスイッチを使用した際に同じ不具合起こしていたものですが、こちらも改修されました。もちろん、-XX:+AggressiveOptsのような"experimental"なJVMオプションを本番環境で使うべきではありませんけれども！私たちは、すべての人にこの最新バージョン6u29にアップグレードすることをお奨めいたします。

なお、Java 7にアップグレードする際は、インデックスを再作成するようにお願いします。Java 7でリリースされるユニコードのバージョンが変わるため、トークナイズの振る舞いが異なるためです（小文字など）。詳しくは各リリースパッケージのJRE_VERSION_MIGRATION.txtファイルを参照してください！

Apache Lucene/Solr コミッターを代表して、
Uwe Schindler

• [1] http://www.oracle.com/technetwork/java/javase/7u1-relnotes-507962.html
• [2] http://www.oracle.com/technetwork/java/javase/6u29-relnotes-507960.html

Solr 3.4なのにSolr 3.5の新機能までわかってしまう、最新情報満載のロンウイットのSolrトレーニング・・・Solr 3.4 11月 トレーニング受講者募集まもなく締め切り！

BooleanQueryで検索にヒットするはずのドキュメントが漏れる不具合が先日リリースされたばかりの2.9.0で発覚した。同じテストコードは2.4.1では出ないので、2.9.0で新たに入り込んだバグである。すでに修正され、2.9.1に含まれる。2.9.1にはFastVectorHighlighterの修正も含まれる。

BooleanQueryの不具合
https://issues.apache.org/jira/browse/LUCENE-1974

FastVectorHighlighterの不具合
https://issues.apache.org/jira/browse/LUCENE-1953

Solr 1.4はRCを現在準備中だが、Lucene 2.9.1を取り込む予定である。

Lucene 2.3まではDocumentにadd()した（名前の異なる）Fieldの順番は、IndexReader/IndexSearcherで取得したDocumentに対してfields()/getFields()を実行して取得したときにも順番が保たれていた。ところが、LUCENE-1301の機能改善の時にこのルールが破られてしまった。現在、Lucene 2.9でこれを元に戻そうとしている：

https://issues.apache.org/jira/browse/LUCENE-1727

したがって、狭間のLucene 2.4ではDocumentに対してfields()/getFields()を実行して取得したFieldのリストは保存時の順番とは異なってしまう不具合が残ったままである。

なお、マルチバリュー（multi valued;Documentに対して同じフィールド名で2つ以上のフィールドをadd()すること）の順序はいずれのバージョンでも保たれている。

Lucene 2.3で作成したインデックスをLucene 2.4にアップグレード（Luceneライブラリを2.3から2.4にアップグレードし、2.3で作成したインデックスを2.4で更新すればインデックスは2.4フォーマットに自動的に変換される）したときに、もしフィールド名に日本語などnon-ASCIIキャラクタを用いていると、"read past EOF"例外に出会う可能性がある不具合が報告されている。例外にならなくても正しいフィールド名が返らない可能性がある。

この不具合はLucene 2.9で修正される予定である：

https://issues.apache.org/jira/browse/LUCENE-1623

Lucene 2.3.1以前のバージョンを使用していたアプリケーションが、Lucene 2.4にアップグレードした際、実行時の動作が異なってしまう可能性があることが判明し、メーリングリストで注意喚起されていたので、ここで紹介しておこう。

1. QueryParserを拡張し、addClause()やgetBooleanQuery()をオーバーライドしていたアプリケーションは、（従来のVectorではなく）List引数を使用する新しいメソッドを使わなければ、フレームワークから呼ばれなくなってしまう。addClause()やgetBooleanQuery()はList引数を使用する新しいメソッドを使うように書き直す必要がある。


2. DocumentクラスのgetFieldables(), getFields(), getValues()およびgetBinaryValues()を使っているアプリケーションは、これまで戻り値のnullチェックをしているところを.size()の長さ0チェックに変更する必要がある。

Java 1.6.0_10で改修されたと見られていた現象がいまだ発生するという報告があった：

https://issues.apache.org/jira/browse/LUCENE-1342

すでにSunに報告済みでAcceptされているとのこと。非常にまれにしか発生せず、再現が難しいバグのようである。

先日お知らせしたJava 1.6.0_04以上で発生する不具合だが、OpenJDK上ですでに改修されており、Java 1.6.0_10に反映されるようだ。

さて、先日の週末はパソコンの復旧でつぶれた私だが、容量アップしたハードディスク（60GBから120GB）にいろいろソフトをインストールして現在は復活している。インストールしたソフトは特に理由がなければそのときの最新バージョンを入れた。Javaは1.6.0_07に上がったので、LUCENE-1282で騒がれた不具合が再現するか試してみた。

この不具合はJavaのHotSpot Compilerのものとみられており、SunのBug Databaseにファイルされている：

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6707044

上記URLには再現させるための簡単なプログラムが掲載されている。私の環境（Windows Vista）で実行してみると、確かに再現した（起こるはずのないRuntimeExceptionが発生する）：



ただし、上記URLに掲載されているプログラムそのままでは私の環境では起こらず、LUCENE-1282にあるとおり、docNumを1000000に、jを300000に変更すると発生した。

上記バグは当初はSunによりプライオリティがLowでファイルされていたが、現在は88票もの投票を受け、プライオリティがHighに変更されている。

LUCENE-1282
https://issues.apache.org/jira/browse/LUCENE-1282