lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <DOR...@il.ibm.com>
Subject RE: IndexWriter shutdown
Date Wed, 23 May 2007 18:56:05 GMT
"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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message