lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From iouli.golova...@group.novartis.com
Subject Re: weird lock behavior
Date Fri, 27 Aug 2004 09:01:01 GMT
Otis, 

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

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.






>Iouli,

>This sounds like something that should never happen.  It never happens
>for me at simpy.com - 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.

>Thanks,
>Otis




Bernard,

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).



hi,

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)) {
    IndexReader.unlock(dir);
}
dir.close();

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

fun with it
Bernhard

iouli.golovatyi@group.novartis.com wrote:

>Hi,
>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 
no 
>idea which lock file to kill).
>
>
>
> 
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org




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