lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Is there a way to share IndexReader data sensibly across independent callers?
Date Tue, 09 Feb 2016 08:59:32 GMT
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

On Tue, Feb 9, 2016 at 12:12 AM, Trejkaz <> wrote:
> On Tue, Feb 9, 2016 at 2:10 AM, Sanne Grinovero
> <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message