On Wed, Feb 1, 2012 at 1:14 PM, Robert Muir <rcm...@gmail.com> wrote:
>
> No, I don't think you should use close at all, because your problem is
> you are calling close() when its unsafe to do so (you still have other
> threads that try to search the reader after you closed it).
>
> Instead of trying to fix the bugs in your code, I suggested using
> SearcherManager, which uses IndexReaders reference counting API (or
> you can use that directly alternatively).
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.
TX
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
