lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: 10Gb of .nfsXXX files about a week old in NFS based index directory
Date Wed, 10 Sep 2008 09:28:53 GMT

David Loeng wrote:

> Hi,
>
> We have a customer using lucene on an NFS directory, which contains  
> ~10Gb of .nfsXXXX files. These files are the means by which NFS  
> implements delete-on-close semantics (that is, if the index writer  
> commits a delete of a file that is still held open by an index  
> reader, the file is renamed to .nfsXXXXX).

As long as the held-open file as well as the delete take place from  
the same machine, then those .nfsXXXX files will be created.

> The version of Lucene in use is 2.2.
>
> Our IndexSearcher is refreshed almost every minute (new  
> IndexSearcher(Directory directory)) depending on whether content has  
> been added/updated/deleted.
>
> What must be done to guarantee that lucene does not hold onto files  
> that have been deleted?
>
> Can a dereferenced IndexSearcher (closeReader=true) which has not  
> been close()-ed cause lucene to be holding onto file handles of  
> deleted index files?

You really should call close() on any IndexSearcher you created.

Lucene's FSDirectory.FSIndexInput.Descriptor class does have a  
finalizer that calls close, however, it's not a good idea to rely on  
that.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message