ot be a problem as an IndexReader will be opened, not a
second IndexWriter.
Ross
-Original Message-
From: Dan Armbrust [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 3:10 PM
To: java-user@lucene.apache.org
Subject: Re: how long should optimizing take
You should be careful, ho
You should be careful, however, not to end up with two VM instances each
trying to open an index writer at the same time - one of them is going
to fail.
Aka, if someone using your web interface tries to add a new document to
the index while you have the optimizer running standalone, the web
i
n a weekly bases.
Ross
-Original Message-
From: Dan Armbrust [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 11:10 AM
To: java-user@lucene.apache.org
Subject: Re: how long should optimizing take
I would run your optimize process in a separate thread, so that your web
client doesn
Hi,
optimize() merges the index segments into one single index segment. In
your case, I guess the 2G index segment is quite large, if you merge
it with any other small index segments, the merging process definitely
will be slow.
I think the performance should be ok without calling optimize().
Mor
I would run your optimize process in a separate thread, so that your web
client doesn't have to wait for it to return.
You may even want to set the optimize part up to run on a weekly
schedule, at a low load time. I probably wouldn't reoptimize after
every 30 documents, on an index that size.
I would like to bring that issue up again as I haven't resolved it yet and
haven't found what's causing it.
Any help, ideas or sharing experience are welcome!
Thanks,
Ross
-Original Message-
From: Angelov, Rossen
Sent: Friday, May 27, 2005 10:42 AM
To: 'java-user@lucene.apache.org'
Subj
