[
https://issues.apache.org/jira/browse/LUCENE-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539253#comment-13539253
]
Uwe Schindler commented on LUCENE-4246:
---------------------------------------
{quote}
bq. Although close() may do more than just closing (if autocommit is enabled,
it may also commit), they decided to add Closeable (e.g., see
http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html) - but the
discussion here was similar.
That's an interesting precedent. Uwe do you a pointer to the discussion?
{quote}
I am digging... I have no pointer at the moment, I just read blog posts and
followed some mailing lists at that time, but that's now almost 2 years ago.
The SQL stuff had more problems, which lead finally to the new interface
AutoCloseable in Java 7 (java.io.Closeable extends java.lang.AutoCloseable).
The reason is: SQLException does not extend IOException so the already existent
java.io.Closeable was not applicable, so the new java.lang.Autocloseable was
defined to throw any Exception subclass on its close() method, just
java.io.Closeable limits this to IOException by subclassing. The
try-with-resources magic in Java 7 only affects AUtocloseable, but as Closeable
extends Autocloseable, it also applies to Closeable.
Unless we move to Java 7 we are also limited to only throw IOException on
close(), no other checked Exception. In Java 7 we could make IndexWriter
implement AutoCloseable and let it throw any other Exception, too.
One important information about AutoCloseable from JavaDocs: "Implementers of
this interface are also strongly advised to not have the close method throw
InterruptedException. This exception interacts with a thread's interrupted
status, and runtime misbehavior is likely to occur if an InterruptedException
is suppressed. More generally, if it would cause problems for an exception to
be suppressed, the AutoCloseable.close method should not throw it. Note that
unlike the close method of Closeable, this close method is not required to be
idempotent. In other words, calling this close method more than once may have
some visible side effect, unlike Closeable.close which is required to have no
effect if called more than once. However, implementers of this interface are
strongly encouraged to make their close methods idempotent."
This last sentence explains why java.sql.Connection is not required to be
idempotent (see below). :-)
bq. So I think another option here is to leave close as is (it waits for
merges, commits) except, if an exception is thrown, it suppresses that
exception, finishes closing, and then throws it. Like IOUtils.close.
I am fine with that, only that it *must* record suppressed Exceptions
(unfortunately the IOUtils in Lucene is in most cases used not in the optimal
way, so the supressed exceptions get lost).
bq. Hmm... does java.io.Closeable document semantics on exception? Ie if I call
RAF.close and hit an exception, is it "really closed"? It does document that
calling it more than once is fine ...
It says that you may call close() multiple times, but later calls mst be
side-effect free, so after the first call to close it must be closed (otherwise
later calls would have side-effects), although an IOException is thrown.
> 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]
