You are right, its not clean. However, this aproach gave me a fair balance
between cleaness and geting the app to market. Using a reference counter is
more correct, but adds complexty in order to do it right. Restarting the vm
only resets the clock, however this is a reality of the vm.
------Mensaje original------
De: shaoxianyang
Para: [email protected]
Responder a: [email protected]
Asunto: Re: IndexSearcher close() and search() called concurrently bydifferent
threads?
Enviado: 29 Sep, 2009 23:11
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.
Enviado desde mi BlackBerry de movistar Profesional
(http://www.movistarempresas.com.ar)
