Hi, thanks for responding. A quick follow-up, the problem turned out
to be more complex than originally explained, and it was not in fact a
problem with buggy behavior in Lucene. A static nested class created
a fugly point where I was holding/using the wrong reader at the time
of failure.
-M
On Jan 22, 2009, at 2:57 PM, Michael McCandless wrote:
IndexReader.open opens the latest segments_N file. If that file
references only 1 segment, a SegmentReader is returned, else a
MultiSegmentReader.
I'm confused why you see the SegmentReader impl giving too few
results -- that should only be returned if your index legitimately
has only 1 segment. Are you sure the SegmentReader impl is not
returning the right results? Do you have an example index which
IndexReader.open consistently incorrectly returns a SegmentReader?
Is an IndexWriter changing the index when you call IndexReader.open?
Mike
Micah Jaffe wrote:
My environment:
Lucene 2.3.2 on Linux, Java 1.6.0_07-b06, running under Tomcat 5.5.26
What I'm trying to do seems pretty simple, but is causing a
headache which I can't sleuth out. When I try to build an
IndexSearcher using an IndexReader, the
IndexReader.open( String_to_index_dir ) call sometimes creates a
reader with a SegmentReader impl. Other times a MultiSegmentReader
will be created. The SegmentReader impl when used returns a much
reduced or empty result set from searchers; the MultiSegmentReader
returns the right and expected results from the index.
The indexes I'm using were built initially optimized, but will not
remain so until they are rebuilt from scratch (usually weekly).
The indexes are being constantly updated and searched on in the
Tomcat environment.
I noticed in the guts of the DirectoryIndexReader it will seem to
pick SegmentReader over MultiSegmentReader if the index is
optimized. Is there any way to make this code always return a
MultiSegmentReader? Why is one reader failing over the other?
This appears to be a bug (and a nasty one for me).
Any help or guidance would be much appreciated as I've already
spent a day trying to dig through these mechanics and am a little
lost. Please no, "Upgrade to 2.4 and then see what happens." 2.4
appears to include a lot of interesting things but also deprecates
a lot of API which I do not have time to dig into or refactor.
thanks,
Micah
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org