lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From shaoxianyang <ysxsu...@hotmail.com>
Subject Re: IndexSearcher close() and search() called concurrently by different threads?
Date Wed, 30 Sep 2009 02:11:37 GMT

Hmm,

I looked at the lucene code, now I even worry more about memory leak in
addition to the original holding up the file descriptor (OS level).

IndexSearcher.close() will close the underlying IndexReader (in our case,
DirectoryIndexReader, which in turn close FSDirectory (we are using file
based index, not RAM).  The close logic in RAMDirectory will remove the
file<-->FSDirectory map entry from a class level global map.  Without
closing it, it is just memory leak, plus holding up the file descriptor at
os level.

  public class FSDirectory extends Directory {
  
    private static final Map DIRECTORIES = new HashMap();
  /** Closes the store to future operations. */
  public synchronized void close() {
    if (isOpen && --refCount <= 0) {
      isOpen = false;
      synchronized (DIRECTORIES) {
        DIRECTORIES.remove(directory);
      }
    }
  }


I understand your point that memory leak is not too prominent and not hold
up too many files (depending on how often you rebuild index).  Then restart
server once a month restart the clock for the problem.  Am I getting it
right?

If so, I still think this is not clean enough.  Am i on the wrong track to
solve the problem?  Is there any cleaner way of doing so?  I am not
considering synchronize close() and search() operation, BTW.


Thanks.



Shaoxian Yang
-- 
View this message in context: http://www.nabble.com/IndexSearcher-close%28%29-and-search%28%29-called-concurrently-by-different-threads--tp25667782p25673915.html
Sent from the Lucene - General mailing list archive at Nabble.com.


Mime
View raw message