私のJavaプロセスのファイル記述子が「悪い」となっていて、なぜわかりません

Question

私はLuceneで構築されたJava Webアプリケーションを持っていて、さまざまな「ファイルがすでに閉じられています」という例外があります。 Luceneからjava.io.IOException Bad File Descriptorとjava.nio.channels.ClosedChannelExceptionを取得できました。通常、IndexReaderのAlreadyClosedExceptionをラップします。

面白いことに、私はIndexReaderをクローズしていないし、ファイル記述子が独自に古くなっているようだ。私は最新のバージョンのLucene 3.0（3.0シリーズからアップグレードする時間がなかった）、OracleのJDK6の最新バージョン、Tomcat 6の最新バージョン、CentOSの最新バージョンを使用しています。他のLinuxシステムと同じソフトウェアでバグを再現することはできますが、Windowsシステムでは実行できません。テストするOSX PCはありません。 LinuxサーバはqEmuで仮想化されています。

これは負荷に関連しているようにも見えます - この頻度は、Tomcatが（この特定のWebアプリケーションに）提供している要求/秒の量に相当します。たとえば、1つのサーバーでは、要求が〜2 reqs/secを処理するまで期待どおりに完了します。その後、約10％はファイルディスクリプタを中間リクエストからクローズします（コードは有効なIndexReaderオブジェクトをチェックし、要求の処理の開始時に1つ作成します）。約3 reqs/secに達すると、すべての要求が不良ファイル記述子で失敗し始めます。

OSのレベルで何とかリソースが枯渇し、OSがファイルをクリーンアップしていると私は推測しています...しかし、それは単純に私が持っていたすべてのアイデアを排除したからです。私は既にulimitsとファイルシステムfdの制限をチェックしており、オープンディスクリプタの数はいずれかの制限値（例えばsysctl fs.file-nrからの出力例：1020 0 203404、ulimit -n：10240）のかなり下です。

私はテストの対象からほとんど外れています。私はそれを見つけた日よりも、これを解決するために近くにいません。誰も似たような経験はありますか？

EDIT 07/12/2011：いくつかのテストに使用するOSXマシンが見つかりました。これがOSXで発生することが確認されました。また、物理的なLinuxボックスでテストを行い、問題を再現しました。この問題を再現できなかった唯一のOSはWindowsです。これは、2つのテストシステム（JDKバージョン、Tomcatバージョン、およびwebappはすべてのプラットフォームですべて同一）の唯一の関連する違いと思われるため、これはPOSIXのファイル記述子の処理と関係していると思います。

Answer 1

Windowsでこのようなことが起こっていないと思われる理由は、そのFSDirectory.openがデフォルトのSimpleFSDirectoryを使用している可能性があります。 FSDirectoryとNIOFSDirectoryの上部に

チェックアウト警告を：http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/store/NIOFSDirectory.htmlで赤のテキスト：

注：場合は、それが中断している間のスレッドから直接または間接的に、このクラスにアクセスするとすぐに、基礎となるファイルディスクリプタを閉じることができます同時にスレッドはIO上でブロックされます。ファイル記述子は閉じたままであり、その後NIOFSDirectoryにアクセスするとClosedChannelExceptionがスローされます。アプリケーションがThread.interrupt（）またはFuture.cancel（ブール値）のいずれかを使用している場合、あなたはNIOFSDirectory

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