"Michael McCandless" wrote: > That's correct. > > On seeing the "shutdown in progress" exception, the current "finally" > clause in mergeSegments would revert the internal state of the > IndexWriter to be consistent, ie, put back the segments that were in > the process of being merged into its segmentInfos. It will also > remove any partially created but now unusable newly merged segments > files. > > If the application catches this exception and calls > IndexWriter.close(), then the state until just before the aborted > merge would be committed to the index. If instead the application > catches the exception and does nothing, then the state of the index > reverts back to where it was when this IndexWriter instance was first > opened. > > So the semantics of autoCommit=false will be correctly enforced if any > exception (not just this new one) comes up through mergeSegments.
Great. So my comment on Antony's "mini-optimize" scenario was partially wrong, because under autcCommit=true (which is the default), those sub-merges that completed before shutdown are not lost, only the last one, the one that was interrupted. Mmmm... I can see how autocommit=true works fine, because anything (auto)committed is already saved, and there is no need to write anything more. But for autoCommit=false it is not clear to me how such further call to indexWriter.close() by the application can work - because a shutdown state is in effect, and any attempt to write/flush anything would just throw the same exception again... or am I missing something? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
