Our setup is quite similar to yours, but in all honesty, you will need
to do some for of batching on your updates simply because, you don't
want to keep the Index Writter open all the time.
As for clustering, we went through three iterations, that keep x indexes
parallelized on x servers all o
Nader Henein wrote:
Our setup is quite similar to yours, but in all honesty, you will need
to do some for of batching on your updates simply because, you don't
want to keep the Index Writter open all the time.
For now, the index writer is closed after each added document. It does
not seem to
As far as indexing is concerned, a simple way of tracking a clustered
system, is to create autonomous indecies that report to a central
repository, creating a table in the DB with a row per document ( you
have a unique document ID, right? ) and then a column per server node
(the columns act as
Hi,
I am looking at and trying to understand more about Lucene's
reader/writer synchronization. Does anyone know when the commit.lock
is release? I could not find it anywhere in the source code.
I did see the write.lock is released in IndexWriter.close().
Thanks,
Jian
-
Why not try using JMS messaging to send messages to the indexing
server that Document X needs to be updated via a JMS queue? This
gives you the flexibility to have the indexing system down but not
lose the message that it needs to be indexed, and also allows the
indexing server to be 'busy
Thanks for the idea. I have tried with both 512m and 1024m with the same
results. I also turned on verbose gc logging. Once I see this slowdown, the gc
is running only once every 12 minutes or so and finishes in less than 0.005
seconds.
Its basically stuck at 100% cpu usage, but doesn't seem t
