Thanks for getting this in! Just a couple of questions:
Are changes to the index transactional in nature? In other words, can an index ever get in an inconsistent state by killing the writing process? If so, is there any way to detect this?
Can you describe where the synchronization points/locks are now and how they work? (I want to make sure to avoid any situations that might cause any performance degradation or deadlock.)
> -----Original Message-----
> From: Doug Cutting [mailto:DCutting@grandcentral.com]
> Sent: Thursday, September 27, 2001 12:53 PM
> To: 'Scott Ganyo'; 'email@example.com'
> Cc: 'firstname.lastname@example.org'
> Subject: RE: [Lucene-dev] Index integrity check and fix?
> > From: Scott Ganyo [mailto:scott.ganyo@eTapestry.com]
> > We're still having occasional problems with indexes getting the
> > error (in Lucene 1.1 release):
> > java.io.IOException: /index/_1x7f.fnm already exists
> > when updating records. I'm not positive where this is coming from,
> > but I'm guessing that it is from when we have to forcefully stop the
> > service since all access to the index is synchronized.
> With the file locking code that I just checked in (to Jakarta, not
> Sourceforge) you should not have this problem anymore.
> Instead, if Java
> exits unexpectedly, you might now find a .lock file left in
> the index that
> will prevent restart. In this case, I recommend removing all
> .lock files
> before restarting your application, when you are certain that no
> applications are currently accessing the index. Is that acceptable?
> BTW, this is the last message I will send to
> email@example.com. Henceforth I will use
> firstname.lastname@example.org. Please subscribe to that list
> if you would
> like to stay involved with Lucene development. The Jakarta
> lucene-user list
> and Lucene website are still under construction, but Lucene
> development has
> moved to Jakarta.