lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Ritchie <>
Subject Re: Compound file index issue
Date Thu, 22 Jan 2004 21:08:48 GMT
Hani Suleiman wrote:

 > 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.
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
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
interval should be decreased to maybe 50 ms or the lockWaitTimeout should be increased. In
I believe the ++sleepCount should really be sleepCount++ so it will at least run once even
nothing else is changed. The second issue is that I don't believe that code should throw the
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

I'll create a bugzilla issue with a proposed diff later today.


Bruce Ritchie

View raw message