lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Lock on old index files
Date Wed, 02 Dec 2009 20:05:11 GMT

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


Mime
View raw message