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
--- [EMAIL PROTECTED] wrote:
> Otis,
>
> no idea how I run into it. That's why to create a unit is a bit
> problematic.
>
> In Lucene code it lo
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,
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
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)) {
Inde
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 beh
