Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <14046340.1172951511416.JavaMail.jira@brutus>
Date: Sat, 3 Mar 2007 11:51:51 -0800 (PST)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-818) IndexWriter should detect when it's
 used after being closed
In-Reply-To: <31514116.1172518447790.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477670 ] 

Yonik Seeley commented on LUCENE-818:
-------------------------------------

> On the thread safety issue: are you saying if one thread closes the
> reader while another thread is using it, there is uncertainty excactly
> when the 2nd thread will hit the AlreadyClosedException (because of
> how the JVM schedules the threads)?

Yes, but it's not just thread scheduling, it's also lack of memory barriers.  The 2nd thread may *never* see the close(), depending on the exact architecture of machine and the JVM.

> I think this kind of thread behavior is normal/expected? 

For a class that isn't thread safe, yes.  IndexReader is advertised as being thread safe though.  If we guarantee an exception accessing a closed reader, then that should work 100% of the time. I don't think we should make that guarantee. 

We can still throw meaningful errors in more cases and make it easier for the user to debug that, but it should not be deemed an error if we don't throw an exception.  Users should never rely on getting this exception for flow-control purposes anyway.

> OK how about we do not call ensureOpen() in these IndexReader methods?:
>  numDoc()
>  maxDoc()
>  isDeleted() 

+1

hasDeletions() too?

> > what about setting more things to null when a reader is closed?
> Well ... I would prefer not to increase the frequency of getting "undefined" NPEs out of the reader

Yes, but not all bugs will be user bugs.  Some will be internal Lucene stuff that bypass public methods.
It's still better that these fail quicker too.  Anyway, that can be handled on a case-by-case basis later.


> IndexWriter should detect when it's used after being closed
> -----------------------------------------------------------
>
>                 Key: LUCENE-818
>                 URL: https://issues.apache.org/jira/browse/LUCENE-818
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.1
>            Reporter: Michael McCandless
>         Assigned To: Michael McCandless
>            Priority: Minor
>         Attachments: LUCENE-818.patch, LUCENE-818.take2.patch
>
>
> Spinoff from this thread on java-user:
>     http://www.gossamer-threads.com/lists/lucene/java-user/45986
> If you call addDocument on IndexWriter after it's closed you'll hit a
> hard-to-explain NullPointerException (because the RAMDirectory was
> closed).  Before 2.1, apparently you won't hit any exception and the
> IndexWrite will keep running but will have released it's write lock (I
> think).
> I plan to fix IndexWriter methods to throw an IllegalStateException if
> it has been closed.

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org