Hi, I've implemented a class to reopen IndexReaders using atomic counters, we call this kind of service "ReaderProvider" in Hibernate Search; feel free to give a look and comment about it:
http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/reader/SharingBufferReaderProvider.java?r=16210 I'ts more complex than what you need, as Hibernate Search's API requires me to take care of reopening not just an IndexReader on a Directory but a Multi-Reader on a list of Directories, each being checked for updates. It's considered stable and no problems are being reported; However I've seen recently that the IndexReader is now having an internal counter of references being used during reopen(), which possibly enables me to make the code simpler (But I'm not going to change working code, just a hint for you). Regards, Sanne 2009/9/30 <[email protected]>: > 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)
