In the process of debugging I noticed some code in the Lock class that I believe is not ideal. In the method obtain(long lockWaitTimeout) you'll see the following code:
int maxSleepCount = (int)(lockWaitTimeout / LOCK_POLL_INTERVAL); int sleepCount = 0; while (!locked) { if (++sleepCount == maxSleepCount) { throw new IOException("Lock obtain timed out"); }
I believe there are a few issues with that code. The first one being that maxSleepCount is always going to be 1 with respect to locking an IndexWriter with the current implementation (1000/1000). This makes the sleep code rather pointless as it will never really runI believe either the poll interval should be decreased to maybe 50 ms or the lockWaitTimeout should be increased. In addition I believe the ++sleepCount should really be sleepCount++ so it will at least run once even if nothing else is changed.
Actually, this was intentional. It ensured that the existing behavior was maintained for backward compatibility. It could certainly be reevaluated, however, now that (I think) we're allowing incompatible changes to the Lucene core for the next release.
The second issue is that I don't believe that code should throw the above exception; rather it should just return false. Throwing an exception should indicate something happened that could not be handled properly, the above usage is IMHO incongruent with the API.
This, too, was written this way specifically to minimize disruption to existing code and patterns. On the other hand, I think you'd probably want to throw the Exception anyway since you really can't recover from it...
Scott
smime.p7s
Description: S/MIME cryptographic signature
