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]
