Thanks Yonik for the clarifications, and for the prompt replies. Now, God
forbidding, I should be fine, and shouldn't be losing my sleep :-)
Thanks again to Yonik and Mike.
Ajay Garg
Yonik Seeley wrote:
>
> On Feb 3, 2008 11:44 AM, ajay_garg <[EMAIL PROTECTED]>
> wrote:
>> Firstly, in the 2.3
On Feb 3, 2008 11:44 AM, ajay_garg <[EMAIL PROTECTED]> wrote:
> Firstly, in the 2.3 optimizations, point 4 says ::
> " 4. LUCENE-959: Remove synchronization in Document (yonik)".
>
> Well, what does that mean, since it has already been assured that multiple
> adds, deletes, updates CAN be done by m
Thanks again Mike.
In fact, I have just finished going throught the CHANGE.TXT file, that
mentions the entire journey details of Lucene, right from 1.4 to 2.3. And of
course, got to know many more things.
Just a couple of issues more.
Firstly, in the 2.3 optimizations, point 4 says ::
" 4. LUCE
The write.lock has always been to prevent multiple instances of
IndexWriter (or, IndexReader doing deletes) from operating on the
same index at a time.
Many threads sharing a single instance of these classes has always
been fine.
Mike
ajay_garg wrote:
@Mike.
Thanks for the reply. B
@Mike.
Thanks for the reply. But I had thought that write.lock is there to prevent
multiple additions/updates/deleteDocuments.
Has there been a change recently in this regard ?
Thanks
Ajay Garg
Michael McCandless-2 wrote:
>
>
> That's right.
>
> Each thread can enter IndexWriter.add/upda
That's right.
Each thread can enter IndexWriter.add/update/deleteDocument(s) in
parallel. There are some parts inside IndexWriter that are
synchronized but they are kept to a minimum to keep good thread
concurrency. As you add threads it's best to increase the RAM buffer
at the same ti
@Yonik
So you mean to say, that if two threads have the same instance of an
IndexWriter passed to both of them, and both these threads run on two
different CPUs, then they can write to the index at the same time ?
Yonik Seeley wrote:
>
> On Jan 30, 2008 10:59 PM, ajay_garg
> <[EMAIL PROTECTED
On Jan 30, 2008 10:59 PM, ajay_garg
<[EMAIL PROTECTED]> wrote:
>
> Thanks Mike for your directions.
>
> Yes, I am in fact using a single computer for my application, and your
> saying that in this case, multiple threads with a single IndexWriter wll
> give a better performance. Hmmm. I just wonder
Thanks Mike for your directions.
Yes, I am in fact using a single computer for my application, and your
saying that in this case, multiple threads with a single IndexWriter wll
give a better performance. Hmmm. I just wonder that since each IndexWriter
has a single write.lock, this means that sitt
If you have a single IndexWriter, then the buffer is flushed @ 16 MB
regardless of how many threads are adding to that buffer.
If you are using multiple IndexWriters, writing to separate
directories and then merging at the end, then each one uses 16 MB.
But this isn't recommended for a s
When in doubt, WhitespaceAnalyzer is the most predictable. Note that
it doesn't lower-case the tokens though. Depending upon your
requirements, you can always pre-process your query and indexing
streams and do your own lowercasing and/or character stripping.
You can always create your own analyze
11 matches
Mail list logo
