インデックスのコミット時の動作について詳述されたメール(原文)を見つけたのでその翻訳を掲載しよう。コミュニティの状況について説明し、さらにはコミュニティに解決方法を問うたものとなっている。破壊した件についてこんにちは。コミッターを代表して投稿します。Lucene/SolrとElasticsearchの両方を先ごろテストしたところHotspotまわりを中心に問題が見つかったことはご存知かと思います。9のプレビュー版ビルド40を利用するよう自分たちのテストインフラを先日アップデートしました。これは主にJigsawまわりの問題を確認することが目的でしたが、いくら頑張ってもこのビルドでは問題が発生しないのです。9の最近のコミットでは問題が発生しており(http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e5b66323ae45)、それに相当するのがhttps://bugs.openjdk.java.net/browse/JDK-8066915です。この問題に関連し、自分たちでもhttps://issues.apache.org/jira/browse/LUCENE-6169というスレッドを立てました。アプローチ(すべてのファイルで一度だけ書き込みが行われる)を使っています。Luceneの所定の「コミットポイント」で「コミット」する場合は一時的なファイル名に書き込み、それからこのファイル(およびすべての関連ファイル)でfsyncを実行する形になります。これはファイルチャネルではfc.force()をコールするだけ簡単です。StandardCopyOption.ATOMIC_MOVE)」を使ったアトムのリネームで行われます。OSではリネーム処理が全く見えなくなる可能性があります。LinuxのMANページ(http://linux.die.net/man/2/fsync)にはすべてに以下の記述があります。コールはファイルのあるディレクトリ内のエントリがディスクに書き込まれたことを必ずしも保証するものではない。Luceneでも以下の手順で同じことをしています。APIにこの記述がないため、われわれは「有利な推測」に基づいてこれを行うことになります。Windowsではうまくいかないなど(*)、IOExceptionの例外は必ず発生します。9のFileSystemExceptionでうまくいかないことです。FileSystemExceptionはディレクトリです。社外のLuceneリリースは(前述のように)例外をすべて受け入れるため大丈夫なのですが、テストインフラでは、少なくともLinuxとMacOSXでは動いてしまうのです。最新のコードはhttp://goo.gl/vKhtsWにあります。してもサポートされているOSのディレクトリでfsyncができるようにしておきたいのです。前述のコミットを8u40や7u80のリリースには戻したくないのです。9なら代替案を検討できるのですが。8の既存のセマンティクスを残し、どうしてもFileChannelからREAD/WRITEをしたい場合は単純にエラーを発生させるのでしょうか?基盤OSとlibcはこのようにして処理を行っています。ファイル、ディレクトリ、デバイスなど、ファイル記述子はどこでもオープンできますが、この記述子ではできない処理もあり、例外やエラーが発生する場合もあります。ディレクトリをfsyncするための新しいAPIを追加する(どのファイルタイプでもおそらく可能)。Windowsではディレクトリではこれがうまくいかないのでしょうか?上記のリンクにあるIOUtils.fsync()のような形です。意見や対応方法に関するアドバイスを下さい。Uwe*)ただ、このファイルシステムのセマンティクスはファイルが確実に見えるようにしているため、実際のところは問題ではありません。IOExceptionにマッピングされますが、これは全く問題ありません)。比較のポイント商用検索エンジンを購入した企業担当者は読まないでください。McCandlessFastVectorHighlighterについて解説記事を寄稿しました。