6

別のプロセスで使用されているためファイルを使用できないという例外がスローされることがありますwrite.lockが、これはLucene.Netの非常に単純なテストアプリであり、他のプロセスでは使用されていません。

例外の詳細は次のとおりです。

System.IO.IOException was unhandled
HResult=-2147024864
Message=The process cannot access the file 
     'c:\temp\luceneidx\write.lock' because it is being used by another process.

Source=mscorlib
StackTrace:
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.File.InternalDelete(String path, Boolean checkHost)
    at System.IO.File.Delete(String path)
    at Lucene.Test.LuceneSearchInternal.get__directory() 
    in C:\Lucene.Test\LuceneSearchResumes.cs:line 35

例外をスローする関連コードは、

var lockFilePath = Path.Combine(_luceneDir, "write.lock");

if (File.Exists(lockFilePath))
    File.Delete(lockFilePath);   // THROWS exception sometimes

コードは主にこの記事からのものです。

インデックスはを使用してバックグラウンドスレッドで構築されてTask.Factory.StartNew()おり、WPFGUIはインデックスの構築中に検索を実行します。インデックスにドキュメントを書き込むスレッドは1つだけです。

質問： Lucene.Netインデックスを使用している他のプロセスはどれですか？

4

1 に答える 1

3

提示されたコードが（インデックス作成手順ではなく）検索手順に関連していると仮定すると、インデックスにアクセスしようとするたびにロックファイルを削除しようとしないでください。バックグラウンドスレッドが現在インデックスに書き込んでいるため、例外がスローされています。スレッド自体が削除を処理する必要があるときに、ロックファイルを任意に削除しようとしています。

あなたが投稿した記事では、このメカニズムは、インデックスの書き込み中にシステム/アプリケーションがクラッシュした後、Luceneインデックスを回復するために使用され、ロックされたままになっています。ただし、これはほとんど一般的なケースではありません。CodeProjectの記事では、インデックスへのシングルスレッドアクセスが想定されているため、このアプローチを採用していると思います。

プロジェクトでは、ロックファイルの存在が現在の書き込みアクセスによるものなのか、以前のアプリケーション/システムのクラッシュによるものなのかを確認できる必要があります。コード内のオブジェクトを使用してlock、クラッシュが発生した場合に動的に解放され、2つのケースを区別できます。

于 2013-02-22T13:40:59.143 に答える