[
https://issues.apache.org/jira/browse/LUCENE-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13957801#comment-13957801
]
Shai Erera commented on LUCENE-4246:
------------------------------------
bq. I ran into the issue today that somebody used a NoMergeScheduler and
IW#close() was waiting forever
I've been struck by that too!! and therefore I stopped using NoMergeScheduler,
and I use NoMergePolicy instead.
bq. We recently fixed rollback and given what rollback looks like now I think
it should actually be called close since this is what it does it flushes all
stuff and shuts IW down
I think we should separate rollback()/commit() from close(). When you call
close, you should not silently lose changes -- you have to be explicit about
losing them (rollback()) or committing them (commit()). And we should
definitely not break existing apps who call close() relying on committing
stuff. So if we:
* Detect in close() that you have uncommitted changes or running merges and
throw an exception
* Let you separately call commit/rollback, waitForMerges/abortMerges and close
* Add a sugar commitAndClose (which waits for merges? or takes a boolean?)
Then I think we can make close() just close and releases resources, including
the lock, at all costs (basically what was done just recently). We give
existing apps a very easy migration path -- call commitAndClose(). And we let
more expert apps to decide what to do about merges and pending changes
separately from each other and closing the writer.
> Fix IndexWriter.close() to not commit or wait for pending merges
> ----------------------------------------------------------------
>
> Key: LUCENE-4246
> URL: https://issues.apache.org/jira/browse/LUCENE-4246
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: 4.8
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
