lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott ganyo <>
Subject Re: Compound file index issue
Date Thu, 22 Jan 2004 22:17:02 GMT
> 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 


View raw message