> Bruce, the lockfiles being left over previously was due to the bad file > locking (the timestamp bug) which would occur fairly frequently on > linux, so I'd say you should enable that as the root cause has been fixed.
After much investigation and tracing I discovered what I believe was the core issue - we had overlooked the fact that when deleting content via an IndexReader it *must* be closed prior to an IndexWriter being opened. With lock files disabled this issue did not seem to raise any exceptions as one would expect.
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 run. I 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. 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.
I'll create a bugzilla issue with a proposed diff later today.
Regards,
Bruce Ritchie
smime.p7s
Description: S/MIME Cryptographic Signature
