Erick & Steven,
I looked at 845, but I'm a bit confused:
Are you suggesting that 845 is the cause for the spikes seen in test
Runs 1 & 2 - and that in 2.1 addIndexesNoOptimize() is, under the
covers, relying on calls to ramSizeInBytes() to trigger new segment
creation before hitting the 10,000 v
Michael,
Our application includes indexing and archiving documents to meet
compliance requirements.
A couple of reasons that lead to the merge approach:
- Source documents are written to archive media and retrieval is
relatively slow. Add to that our processing pipeline (including
text extrac
Our application includes an indexing server that writes to multiple
indexes in parallel (each thread writes to a single index). In order
to avoid an OutOfMemoryError, each request to index a document is
checked to see if the JVM has enough memory available to index the
document.
I know that Index
First, are you sure you're free memory calculation is OK? Why not
just use freeMemory?
I _think_ my calculation is ok - my reasoning:
Runtime.maxMemory() - Amount of memory that can be given to the JVM -
based on -Xmx
Runtime.totalMemory() - Amount of memory currently owned by the JVM
Runtime.
I see my tables didn't come through so well. Here's (I hope) a plain
text version:
I understand that it would be best to have a UI that mapped lists of
terms to MUST, MUST_NOT and SHOULD, but I'm currently constrained to
using the QueryParser with boolean operators.
Given that, I was thinking th
Pilot error... I had a cut & paste error and was indexing "C D" as the
document I said I was indexing as "D". Sorry about that.
Thanks, david.
On 5/16/07, Doron Cohen <[EMAIL PROTECTED]> wrote:
> Query Parsed As Matches Matches
> - -
