lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
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  


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message