[
https://issues.apache.org/jira/browse/LUCENE-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724055#action_12724055
]
Shai Erera commented on LUCENE-1707:
------------------------------------
bq. I'd actually rather not remove the ensureOpen calls (I think it's better
when the user sees an AlreadyClosedException than an NPE from somewhere deeper
in IndexReader), but instead change it to a best effort impl (ie don't use
volatile).
I agree that it's better to see ACE than NPE. However, I thought we agreed that
nearly all applications do not rely on ACE. And even if we make it super fast,
I still don't see why for a properly written application, which knows it does
not access a closed reader/writer we should check ensureOpen(). And, our merge
code calls document() while reading from an IndexReader, which obviously cannot
be close, so why check there?
True, ACE helps developers of good apps, which "forgot" they closed the reader
few lines above, track the problem faster ... But then this issue becomes just
changing refCount to not volatile? And nothing to do on IndexWriter? If that
was the intention, then I don't think an issue is needed, and a committer can
just commit this one line change?
> Don't use ensureOpen() excessively in IndexReader and IndexWriter
> -----------------------------------------------------------------
>
> Key: LUCENE-1707
> URL: https://issues.apache.org/jira/browse/LUCENE-1707
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Shai Erera
> Fix For: 2.9
>
> Attachments: LUCENE-1707.patch
>
>
> A spin off from here:
> http://www.nabble.com/Excessive-use-of-ensureOpen()-td24127806.html.
> We should stop calling this method when it's not necessary for any internal
> Lucene code. Currently, this code seems to hurt properly written apps,
> unnecessarily.
> Will post a patch soon
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
