eSubReaders=false when you create your MultiReader?
This way, the MultiReader incRefs on init and decRefs on close.
But: what Lucene version are you using...?
Mike
http://blog.mikemccandless.com
On Tue, Apr 26, 2011 at 8:46 AM, Alexey Lef wrote:
> This is the code in IndexReader.close():
This is the code in IndexReader.close():
public final synchronized void close() throws IOException {
if (!closed) {
decRef();
closed = true;
}
}
What strikes me as odd is that “closed” variable is set to true regardless of
whether the index was actually closed using doClo
010 at 11:31 PM, Alexey Lef wrote:
> I believe there is in fact a difference between 2.4.1 and 3.0.1 as far as
> leaking file descriptors is concerned. When sharing an IndexSearchere among
> multiple threads, instead of closing an old IndexSearcher/IndexReader, we
> used to follow t
I believe there is in fact a difference between 2.4.1 and 3.0.1 as far as
leaking file descriptors is concerned. When sharing an IndexSearchere among
multiple threads, instead of closing an old IndexSearcher/IndexReader, we used
to follow the good old advice to "just drop it on the floor and let
We use MultiSearcher for a similar scenario. This way you can keep the
Searcher/Reader for the read-only index alive and refresh the small index
Searcher whenever an update is made. If you have any cached filters, they are
mapped to a Reader, so the cached filters for the big index will stay ali
We have a very similar situation.
We cache an IndexSearcher for each index and a MultiSearcher for each
combination. Both IndexSearchers and MultiSearchers are created on
demand (i.e. we don't prebuild every possible combination). I think
caching MultiSearchers is not necessary because it is just
