lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: weird lock behavior
Date Fri, 27 Aug 2004 13:24:53 GMT
Yes, creating a unit test that demonstrates things like this is always
a problem, but that's probably the only way we can see what's going on.

Otis

--- iouli.golovatyi@group.novartis.com wrote:

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


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


Mime
View raw message