Michael Busch wrote:
Mark Miller wrote:
Paul J. Lucas wrote:
Also, if you get a ton of concurrent searches, you will have an
IndexReader open for each...not only is this very wasteful in terms
of RAM and time, but as your IndexWriter merges you can have all
kinds of momentary references to normally unneeded index files...get
enough of this going on, and even with the compound file format you
can get too many files open and files missing FileNotFound exceptions.
I disagree, Mark. An IndexWriter should never hit a
FileNotFoundException. If Lucene is being used correctly in Paul's
system, i. e. no other applications (e. g. virus scanners) modify or
remove files in the index directory, then this is likely a bug in Lucene.
Of course it can happen that you run out of available file descriptors
when a lot of threads open separate IndexReaders, and then the
SegmentMerger could certainly hit IOExceptions, but I don't think a
FileNotFoundException would be thrown in such a case.
Paul, is Lucene the only process that modifies the index directory?
Would it be possible for you to try out the current Lucene trunk
version and verify it the error persists? Maybe LUCENE-1044 fixes this
as it makes Lucene more robust in case of machine or OS crashes.
However, since in your case "only" the process gets killed by the OS,
it should still sync the files properly to disk without 1044 I
believe. What do you thing, Mike?
-Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
A bug I have found and ignored then :) Once I reduced the number of
Readers I was generating it stopped. I will see about a test when i get
a minute. I don't think its a Lucene issue, I think the filesystem lies,
and that if you paused and tried again you would find it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
