: Nathan's point about pooling Searchers is something that we also
: addressed by a LRU cache mechanism. In testing we also found that
Generally speaking, you only ever need one active Searcher, which all of
your threads should be able to use. (Of course, Nathan says that in his
code base, doing this causes his JVM to freeze up, but I've never seen
this myself).
I say one "active" Searcher because it might make sense in your
application to open a new searcher after new documents have been added, do
some searches on that new Searcher to "warm" FieldCache for ssorting, and
then close the old searcher and make the new Searcher available to all of
your query threads.
: However his 2nd point is interesting that creating a new index each
: time eventually suffered OutOfMemory (even though he's closing them)
: is a worry. Is this because an IndexSearcher can be closed, but the
: underlying IndexReader is not automatically closed?
As I understand it, the general rule is: if you call IndexReader.open, you
better call .close() on that reader. If you construct and IndexSearcher
using a Directory or a path, then calling .close() on the searcher will
take care of closing the reader -- but if your code look like this...
Searcher s = new IndexSearcher(IndexReader.open(foo))
...then you are screwed, because nothing will ever close that reader and
free it's resources.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
