You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Chris Hostetter <ho...@fucit.org> on 2009/12/02 21:05:11 UTC

Re: Lock on old index files

This is the expected behavior for any lucene based application -- as long 
as an IndexReader is opened on an index, it maintains open filehandles for 
the segments of the index at that moment in time -- as other changes are 
made to the index, new segments are created, and segment merges may result 
in the files being deleted, but the existing IndexReader will keep open 
handles to those deleted files so that it's view of the index is 
consistent.

When you send a commit to solr, it open a new IndexReader, then closes the 
old one ... at that point the filehandles are released, and you should no 
longer see open handles to those deleted files.


: Hi everybody,
: I'm experiencing a problem with my Solr-based web application running on a Sun Solaris OS.
: 
: It seems that the application still holds file-descriptors to index files even if these last ones are removed. It can be observed mainly when the snapinstaller script is executed, but we can find a similar problem on boxes where this script is not used, but only import and optimization commands are executed.
: 
: In particular, if we look at all file descriptors open by the application, we see that, most of times, there are duplicate entries. For example, there are two different Inodes, pointed by two different file descriptors, but if we look more closely at them they are clearly pointing to the same file (size is exaclty the same). The strange thing is that only one of them is actually in the index folder, while the other one is no more there.
: 
: When the application is restarted, duplicate entries disappear and the open file descriptors correctly point to existing files in the index folder.
: 
: Have anyone encountered a similar behavior on his installation?
: 
: Thanks in advance,
: 
: Marco
: 
: --
: The information transmitted is intended for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
: 



-Hoss