re experiencing.
-J
On Tue, Aug 18, 2009 at 9:55 AM, Micah
Jaffe wrote:
Hi, thanks for the response! The (custom) searchers that are
falling out of
cache are indeed calling close on their IndexReader in finalize();
they are
not calling close on themselves as that appears to be a no-op when
hinks it must flush segments far too frequently.
Mike
On Mon, Aug 17, 2009 at 9:31 PM, Micah
Jaffe wrote:
The Problem: periodically we see thousands of files get created
from an
IndexWriter in a Java process in a very short period of time.
Since we
started trying to track this, we saw an in
The Problem: periodically we see thousands of files get created from
an IndexWriter in a Java process in a very short period of time.
Since we started trying to track this, we saw an index go from ~25
files to over 200K files in about a half hour.
The Context: a hand-rolled, all-in-one Luc
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
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
Quick summary of situation (using 2.3.2, StandardAnalyzer):
I've taken a field that was being created as a "default" for a
document, e.g. a giant string of glommed on values from other field
values and instead created a boolean query to hit all the fields which
would normally contribute to
