You're absolutely right, in most cases there would never be a need to
increase the COMMIT_LOCK_TIMEOUT. In fact, if anything, you would
want to decrease it to prevent wait bottlenecks on a system with a heavy
update load. In short, it would be nice to have the option to change it
to suit your system if the need ever occurred. Something to think
about for the future ...
Thanks for the quick response.
Mike Duval
Otis Gospodnetic wrote:
I have never run into this problem, but I'd be curious to know why your system
takes more than 10 seconds to read the segments? Super-large index on a slow
disk? As for new ctors, I suppose they wouldn't hurt, if there really is a
need for them. But 10 seconds is a long time...
Otis
----- Original Message ----
From: Michael Duval <[EMAIL PROTECTED]>
To: Java-user@lucene.apache.org
Sent: Friday, June 9, 2006 12:04:10 PM
Subject: COMMIT_LOCK_TIMEOUT - IndexSearcher/IndexReader
Hi All,
Has anyone else out there come across the shortcomings of the new
COMMIT_LOCK_TIMEOUT in regards to
searching on an actively updated Index?
It used to be a settable system property and therefor "semi" dynamic
across a system with multiple readers/searchers and
one writer. I am aware now that it has access methods for IndexWriter
instances, however, IndexSearcher/Readers that
indirectly need to access the commit lock (to read it's segments) use
the final static COMMIT_LOCK_TIMEOUT in
IndexWriter. There is no way of waiting longer or shorter than the
default (10000) milliseconds.
Perhaps there should be another constructor in IndexSearcher/Reader that
takes commit lock settings allowing for dynamic
blocking based on a particular implementation's needs.
Any thoughts on this?
Thanks,
Michael R. Duval
Senior Programmer/Analyst
American Physical Society
(631) 591-4127
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
