lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Digy" <>
Subject RE: IndexWriter holding on to files?
Date Tue, 18 May 2010 20:51:45 GMT
Hi Josh,
Isn't it possible that your code have some bugs and leave some IndexReaders

What I do for long running Lucene.NET services is:
* I use only one instance of IndexWriter that can be globally accessed.
* I never close the IndexWriter, I use "Commit" whenever needed.( I close it
only when the application terminates).
* I never optimize the Index.
* With every search request, I invoke "IndexWriter.GetReader", make the
search, and close the reader.
* I use Lucene.Net 2.9.2


-----Original Message-----
From: Josh Handel [] 
Sent: Monday, May 17, 2010 11:31 PM
Subject: IndexWriter holding on to files?

   I am working on a Lucene.NET service over WCF.. In order to manage the
single IndexWriter/Reader model (vs one per thread which would be evil slow)
I have some static dictionaries to manage all the available indexes.. I also
have timers so that if an IndexWriter/Reader isn't used for X time it can be
unloaded.. When this happens with a writer I call commit, close.. And that's
all fine, but I am finding that despite the writer and reader being closed
(lock file vanishing and all) segments are being held and locked at the OS
level (learned this attaching to an unloaded index with Luke, which A found
unused files and B couldn't delete them)... In order to clean up these old
segments it looks like I have to bounce my service..

Is there some higher level Lucene cache going on here? Something holding the
indexwriters or their directories after they have been closed?  I would like
to have something that I can add an Optimize API to, and for the most part
would stay clean..

How do others handle long running Lucene.NET services?

Josh Handel
Senior Consultant
512.328.8181 | Main
512.328.0584 | Fax
512.577-6568 | Cell<blocked::blocked::>


View raw message