lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: weird lock behavior
Date Fri, 27 Aug 2004 09:01:01 GMT

no idea how I run into it. That's why to create a unit is a bit 

In Lucene code it looks like that reader tries every 1 sec to read the 
index 10 times. After that it says - it just can not be that it's locked 
so long, I'd query anyway. That's why 10sec delay.


>This sounds like something that should never happen.  It never happens
>for me at - and I use Lucene A LOT there.  My guess is that
>the problem with the commit lock has to do with misuse of
>IndexReader/Searcher.  Like with the memory leak issue, please try
>isolating the problem in a unit test that we (Lucene developers) can
>run on our machines.



it's not a problem to unlock the index. The problem is to know that it's 
the time to intercept and do it manually (i.e. it's not a normal lock came 
from reader/writer proceses but just a fantom that got lost).


the IndexReader class provides some public static methodes to check if 
an index is locked. If this is the case, there is also a method to 
unlock an existing index. You could do something like:

Directory dir = FSDirectory.getDirectory(indexDir, false);
if (IndexReader.isLocked(dir)) {

You also should catch the possible IOException in case of an error or 
the index can't be unlocked.

fun with it
Bernhard wrote:

>I experienced following situation:
>Suddenly my query became too slow (c.10sec instead of c.1sec) and the 
>number of returned hits changed from c. 2000 to c.1800.
>Tracing the case I've found locking file "abc.......-commit.lck". After 
>deletion of this file everything turned back to normal behavior, i.e. I 
>got my 2000 hits in 1sec.
>There were no concurent writing or reading processes running parallely.
>Probably the lock file was lost because of abnormal termination ( during 
>development it's ok, but may happen in production as well)
>My question is how to handle such situation,  find out and repair in case 

>it happens (in real life there are many concurensy processes and I have 
>idea which lock file to kill).

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message