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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
