Ian,
Thanks for you help and patients with me. I started to look at porting
this to a simple self contained example, and I finally found the error in
my code. IndexSearcher.close() doesn't close the underlying IndexReader
when using the constructor new IndexSearcher( IndexReader ). Went back an
Charlie
>From the FAQ
>http://wiki.apache.org/lucene-java/LuceneFAQ#Does_Lucene_allow_searching_and_indexing_simultaneously.3F
"... an IndexReader only searches the index as of the "point in time"
that it was opened. Any updates to the index, either added or deleted
documents, will not be visi
Ian,
>From reading the docs it's seems clear all I need to do is call
IndexWriter.commit() in order for the changes to my single IndexWriter to
be visible to the IndexReader and hence my single IndexSearcher. When you
say "you need to close old readers, you need to reopen readers to pick
up chang
It's hard, impossible for me, to figure out from this what your
problem might be, Multiple indexes, MultiReader, multiple writers
(?), multiple threads?
However I can make some statements: Lucene doesn't leak files, you
need to close old readers, you need to reopen readers to pick up
changes.
Ha
Ok I think I've fixed my original problem by converting everything to use
commit() and never call close() except when the server shuts down. This
means I'm not closing my IndexWriter or IndexSearcher after opening them.
I periodically call commit() on the IndexWriter after indexing my
documents.
Something that did change at some point, can't remember when, was the
way that discarded but not explicitly closed searchers/readers are
handled. I think that they used to get garbage collected, causing
open files to be closed, but now need to be explicitly closed. Sounds
to me like you are openi
Can you show the code? In particular are you re-opening
the index writer?
Bottom line: This isn't a problem anyone expects
in 3.1 absent some programming error on your
part, so it's hard to know what to say without
more information.
3.1 has other problems if you use spellcheck.collate,
you might
Thanks for the reply. I'm still having trouble. I've made some changes to
use commit over close, but I'm not seeing much in terms of changes on what
seems like ever increasing open file handles. I'm developing on Mac OS X
10.6 and testing on Linux CentOS 4.5. My biggest problem is I can't tell
hey charlie,
there are a couple of wrong assumptions in your last email mostly
related to merging. mergefactor = 10 doesn't mean that you are ending
up with one file neither is it related to files. Yet, my first guess
is that you are using CompoundFileSystem (CFS) so each segment
corresponds to a
I'm beginning to think there is an issue with 3.1 that's causing this.
After looking over my code again I forgot that the mechanism that does the
indexing hasn't changed, and the index IS being closed between cycles.
Even when using push vs pull. This code used to work on 2.x lucene, but I
had t
I have a program I recently converted from a pull scheme to a push scheme.
So previously I was pulling down the documents I was indexing, and when I
was done I'd close the IndexWriter at the end of each iteration. Now that
I've converted to a push scheme I'm sent the documents to index, and I
wri
11 matches
Mail list logo
