I learned from reading the available documentation that an instance of IndexSearcher should be used together for search, to ensure optimal performance, and to create any changes made to the index, a new instance must be created. This means that the index is writable (using IndexWriter) after creating an instance of IndexSearcher that points to the same directory. However, this is not the behavior that I see in my Lucene.Net implementation. I am using FSDirectory. RAMDirectory is not a viable option. IndexSearcher blocks one of the index files (in my implementation, it is the _1.cfs file), making the index unrecoverable for the entire lifetime of the IndexSearcher instance.
Is this a known behavior? Can't I restore the index from scratch when using the IndexSearcher instance created before the restore? Is it possible to only modify the index, but not rebuild it?
This is how I create an instance of IndexSearcher:
// Create FSDirectory var directory = FSDirectory.GetDirectory(storagePath, false); // Create IndexReader var reader = IndexReader.Open(directory); // I get the same behaviour regardless of whether I close the directory or not. directory.Close(); // Create IndexSearcher var searcher = new IndexSearcher(reader); // Closing the reader will cause "object reference not set..." when searching. //reader.Close();
This is how I create IndexWriter:
var directory = FSDirectory.GetDirectory(storagePath, true); var indexWriter = new IndexWriter(directory, new StandardAnalyzer(), true);
I am using Lucene.Net version 2.0.
Edit:
Upgrading to Lucene.Net 2.1 (thanks to KenE) and a slight modification to the method of creating my IndexWriter fixed the problem:
var directory = FSDirectory.GetDirectory(storagePath, false); var indexWriter = new IndexWriter(directory, new StandardAnalyzer(), true);
source share