lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Svensson <si...@devhost.se>
Subject Re: This may be a bug
Date Wed, 21 Nov 2012 08:05:05 GMT
Hi,

This does indeed sound serious. Are you saying that you have a snapshot 
(with committed documents) that is cleared when calling 
IndexWriter.Optimize? Can you share it for reproduction purposes?

Are you using near-realtime indexing? What you describe could happen if 
you were using nrt, and never called IndexWriter.Commit. The index would 
indeed be cleared next time an writer is opened against the directory, a 
step in clearing out unused index files. A kind of rollback of 
non-commited changes.

// Simon


On 2012-11-20 16:45, Gerry Suggitt wrote:
> Sorry to send this email directly to the developers, but I couldn't see any other way
of entering a defect.
>
> My name is Gerry Suggitt and I work for Leafsprout Technologies, a company that creates
products for the Medical Information sector.
>
> We have created a Master Patient Index using Lucene that works very well - we are able
to perform fuzzy matching and all the nice things that you want in a MPI.
>
> But something terrible just happened. Fortunately this occured in our own lab - we have
not yet released the product to the field.
>
> Sometime over the weekend, the computers holding the Lucene database rebooted (probably
from a Windows upgrade). All of the Lucene databases were blown away! Completely empty!
>
> Recently, I had noticed the same thing when I was doing some testing, so it may be related.
>
> We are currently using version 2.9.4.1
>
> What I was doing in my testing was taking a snapshot of the Lucene database files (just
a copy to another directory). I would run some tests which would affect the database, so before
continuing I would copy the snapshot back.
>
> When I started the Lucene service, the database was blown away! Completely empty!
>
> I was able to determine what was doing this. At startup, I was performing an optimize.
This seems like a good time for me: At startup we know no client is making demands on the
system. When I commented out the call to optimize, the database remained intact up startup.
>
> The systems that lost their databases still had the call to optimize in them.
>
> Please help!
>


Mime
View raw message