I am trying to cache a BitSet by attaching to IndexReader.addCloseListener,
using the getCoreCacheKey()
But, I find that getCoreCacheKey() returns the IndexReader object itself as
the key.
Whenever the IndexReader re-opens via NRT because of deletes, will it mean
that my cache will be purged, bec
Hi guys,
I have a question about a problem we had with the SearcherManager.maybeReopen()
method. This works as charm except when the segments in the previous index has
the exact same names as the segments in the new one. In this case the
maybeReopen() doesn't load the new index, even though the
Hi guys,
I have a question about a problem we had with the SearcherManager.maybeReopen()
method. This works as charm except when the segments in the previous index has
the exact same names as the segments in the new one. In this case the
maybeReopen() doesn't load the new index, even though the
Hi guys,
I have a question about a problem we had with the SearcherManager.maybeReopen()
method. This works as charm except when the segments in the previous index has
the exact same names as the segments in the new one. In this case the
maybeReopen() doesn't load the new index, even though t
Hi,
> Hello,
> I got an index corruption in production, and was wondering if it might be a
> known bug (still with Lucene 3.1), or is my code doing something wrong.
> It's a local disk index. No known machine power lose. No suppose to even
> happen, right?
>
> This index that got corrupted is upda
No, it's not supposed to happen :)
That exception is happening because IW is trying to apply the deletes
during flush, and needs to open a reader for all existing segments to
do so, and then finds that 33gg.cfs does not exist.
Which is odd, because from your ls -l output, you have no segments
eve
Following up with the structure of the index dir, and checkIndex output.
*Structure of index:*
06/11/2013 10:55 AM .
06/11/2013 10:55 AM ..
02/11/2013 01:06 AM20 segments.gen
01/11/2013 03:00 AM 2,589 segments_29tx
02/11/2013 01:06 AM