Why is Lucene.Net indexer throwing a System.IO.IOException was unhandled?

Question

The exception is thrown up at times saying the file write.lock cannot be used as it is being used by another process, however this is a very simple test app for Lucene.Net and there's no other process using it, any idea of how this may be

The exception details are as follows:

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

The relevant code throwing the exception is,

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

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

The code is mostly from this article.

The index is being built on a background thread using Task.Factory.StartNew() and the WPF GUI does a search while the index is being built. There's only one thread writing documents to the index.

Question: Which other process is using the Lucene.Net index?

Answer 1

Assuming that the code presented is relevant to the search procedure (not the indexing procedure), you shouldn't try to delete the lock file every single time you try to access the index. The exceptions are being thrown because the background threads are currently writing to the index, and you are arbitrarily trying to delete its lock file when the thread itself should handle the deletion.

In the article you posted, this mechanism is used to recover the Lucene index after a system/application crash while it was writing the index, leaving it locked. However, this is hardly the common case. I believe that in the CodeProject article it is assumed a single-thread access to the index, hence the approach it takes.

In your project, you need to be able to check whether the existence of the lock file is due to current write access or to a previous application/system crash. You can use a lock object in your code, which is dynamically freed in the event of a crash, to discriminate between the two cases.