Can't you just call ReaderManager.close? All in-flight operations with that RM will keep working, and the underlying reader will only finally close once they have all finished.
Mike McCandless http://blog.mikemccandless.com On Tue, Feb 9, 2016 at 12:12 AM, Trejkaz <trej...@trypticon.org> wrote: > On Tue, Feb 9, 2016 at 2:10 AM, Sanne Grinovero > <sanne.grinov...@gmail.com> wrote: >> Hi, >> you should really try to reuse the same opened Directory, like you >> suggest without closing it until your application is "done" with it in >> all its threads (normally on application shutdown). >> Keeping a Directory open will not lead to have open files, that is >> probably caused by not closing the instances of IndexReader. >> >> I'd highly recommend to use the ReaderManager for these reasons, >> especially because handling these details across different threads >> both correctly and efficiently can be tricky - I've learned that >> myself when implementing similar things before the ReaderManager was >> created. > > I'm already using ReaderManager, but there are issues. > > I want to close it when the last acquired index has been released, but > no thread knows anything about what indexes other threads could be > using, yet we still want indexes to be closed once nobody is using > them. So I end up having to reference count the ReaderManager, which > seems to defeat the purpose of using it in the first place since I > could just reference count the reader itself. I wish it could handle > automatically closing and reopening the index by itself, but I don't > think it can. > > At the moment I have bolted this additional level of reference > counting around ReaderManager and it just creates a new ReaderManager > when the reference count goes back up to 1 and closes it when it goes > back to 0. But this blob has to be synchronised to implement it safely > and the map for looking these things up can never clean out entries, > because I couldn't find a safe way to do that even using > ConcurrentMap. > > TX > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
