lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: COMMIT_LOCK_TIMEOUT - IndexSearcher/IndexReader
Date Sat, 10 Jun 2006 13:44:02 GMT
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...


----- Original Message ----
From: Michael Duval <>
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 
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?


Michael R. Duval

Senior Programmer/Analyst
American Physical Society
(631) 591-4127

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message