Curious ... Lucene should try to fallback to the older segments_N files (even if segments.gen points to the new, broken ones).
We've removed segments.gen as of 5.x and I think it's unlikely we'll do another 4.10.x release at this point, but maybe still open the issue in case others hit it? Mike McCandless http://blog.mikemccandless.com On Fri, Jul 17, 2015 at 4:37 PM, Geoff Cooney <cooney.ge...@gmail.com> wrote: > Hi, > > We recently had an issue with an index where two sequential aborted but > unsuccessfully rolled back commits resulted in empty segments_n files, > segments_i13p and segments_i13q in this case. This resulted in an > exception whenever we tried to open the index until we manually removed the > bad segments_n files. > > Since the commits were never completed, segments.gen still pointed to > segments_i13o. But it looks like lucene takes the more recent generation > it sees in the file list and never tries to open segments_i13o(which is > openable/uncorrupted in this case). > > My questions is if this is something I should file as a bug? The index is > stored in a remote key-value store. While I have a test that recreates the > issue with an NIOFSDirectory and artificially generated exceptions, I'm not > sure how likely it is that this scenario would actually occur with a local > disk index. > > We are running lucene 4.3. > > Thanks, > Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
