[
https://issues.apache.org/jira/browse/LUCENE-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536341#comment-13536341
]
Shai Erera commented on LUCENE-4246:
------------------------------------
Close() throws an exception -- that's just for back-compat right? I.e., the app
can't do anything with that exception except either calling commit() (that's
the back-compat part) or rollback() (if it needs to close fast). And
abortRunningMerges is just like close(false) today (without the commit())?
I mean, if an app wants to commit + wait + close, the 1 line close() becomes
wait(), commit() and close(). And just like I made a mistake saying you should
call commit() then wait(), I'm sure others will make that mistake too.
So again, why go to great lengths to complicate the lives of the innocent
developer? Can't we just decide (I think that's the 3rd time I'm proposing it)
to never wait for merges on close(), and keep close() committing changes? Would
close() be really simplified if it will need to detect running merges and
uncommitted changes?
Maybe someone puts up a patch with the changes to IW only, so we can review? I
personally don't see the gain in changing the behavior of close(), but maybe a
patch will clarify the gains ...
> 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.1
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
