lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Cooney <>
Subject Lucene segment selection strategy
Date Fri, 17 Jul 2015 20:37:59 GMT

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message