Note that there are actually two concurrency issues to guard against
here:
* Document itself cannot be changed (fields added or removed) from
multiple threads without external synchronization.
* Document cannot be changed from one thread while another thread is
calling
Thanks for the reply Yonik.
Our workflow is as follows:
We build a very large document and put the document on a queue to be
added to our complete index. This queue is serviced by a separate
thread, which actually adds the document to the complete index.
Once the document has been placed on the
Not good! (I'm sorry).
That first exception is worrisome. It's the root cause here.
Can you describe your documents? That exception, if I'm reading it
right, seems to imply that you have documents with 4762 fields. Is
that right?
Are you using multiple threads? Is it possible that
Mike -- Thanks so much for the prompt reply.
You are right, we are accessing these documents with multiple threads
(and have always been). However, I am wondering if the increased
indexing speed in 2.3 has revealed a hidden concurrency issue.
I am going to add in some additional concurrency
On Fri, Feb 29, 2008 at 7:05 PM, Tyler V [EMAIL PROTECTED] wrote:
Mike -- Thanks so much for the prompt reply.
You are right, we are accessing these documents with multiple threads
(and have always been). However, I am wondering if the increased
indexing speed in 2.3 has revealed a hidden
What kind of corruption do you get? Do the files get corrupted
(unusable/unreadable), or do you get multiple items in the index?
-Oorspronkelijk bericht-
Van: Eric Bressler [mailto:[EMAIL PROTECTED]
Verzonden: maandag 29 augustus 2005 23:18
Aan: java-user@lucene.apache.org
Onderwerp:
I was going to send out the answer to this problem this morning. I found
it around 2am last night. I was mistaken that I had corrupt the
indexes. The real problem was that I had forgotten the constructor I
was using for the index reader an had it like
writer = new IndexWriter(indexlocation,
