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]
