lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Lucene appears to use memory maps after unmapping them
Date Wed, 01 Feb 2012 11:25:16 GMT
On Tue, Jan 31, 2012 at 9:42 PM, Trejkaz <> wrote:

> So when we close() our own TextIndex wrapper class, it would call
> decRef() - but if another thread is still using the index, this call
> to decRef() wouldn't actually close the reader. IMO, this wouldn't
> really satisfy the meaning of "close" for the TextIndex.
> Rather, I would prefer to track who is currently using it (which is
> similar to reference counting) and throw some exception which points
> the finger at some code which hasn't correctly terminated so that it
> can be fixed.
> After all, we don't close the text index until after all the GUI
> components have been closed. Each of those is supposed to clean itself
> up, which includes cancelling any tasks which might be accessing the
> text index. If any searches are still going on by the time it gets to
> close(), there is a bug somewhere.

I think you should separate safety (don't close a reader if another
thread is still using it) from bugs in the app.

First and foremost you need to be safe...

Secondarily, figure out why threads are still using the reader when
you don't expect it...

> P.S. Why is the SearcherManager API written in such a way that it
> makes it easy to fail to return the searcher?  Wouldn't it make more
> sense to design it like this?
>    manager.execute(new IndexSearcherLogic() {
>        public void withSearcher(IndexSearcher searcher) throws IOException {
>            // .. logic which might well throw an exception
>        }
>    });
> This way if their block throws an exception you're not relying on them
> remembering to release it in a finally block and it makes it nearly
> impossible to do the wrong thing.

While I do agree this would make things "safer", I don't like APIs
that "invert"; I think it makes the API harder to consume...

Also, if the app really wants this API, they can build it out on top
of the non-inverted API that Searcher/NRTManager provide today...


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

View raw message