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
