Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44899BFA.3010100@aps.org>
Date: Fri, 09 Jun 2006 12:04:10 -0400
From: Michael Duval <duval@aps.org>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: Java-user@lucene.apache.org
Subject: COMMIT_LOCK_TIMEOUT  - IndexSearcher/IndexReader
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org