Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <30847071.1173346044392.JavaMail.root@brutus>
Date: Thu, 8 Mar 2007 01:27:24 -0800 (PST)
From: "Michael McCandless (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_12479273 ] 

Michael McCandless commented on LUCENE-818:
-------------------------------------------

>> People shouldn't have specific application logic for this exception... it should be treated as a program error.
> +1

OK, agreed.  I will remove AlreadyClosedException from all @throws
method signatures.

> Also, another candidate for AlreadyClosedException upon using an already closed (RAM)Directory - came up in http://www.nabble.com/sharing-my-experience-for-upgrading-from-Lucene-1.9-to-Lucene-2.2-dev-tf3366948.html

Yeah I saw this too.  Here's the relevant excerpt:

> 3. RAMDirectory related changes
>   It took me something to find this out. Previously, after
>     ramDirectory = new RAMDirectory(file)
>   I could ramDirectory.close() to release the resources. And later, I
> could do a check for IndexReader.indexExists(ramDirectory) to see if
> there is an index in the directory. FSDirectory behaves this way also.
>   But with lucene 2.2, NullPointerExceptions came out. It turns out
> when ramDirectory.close(), the instance variable fileMap is set to
> null. And IndexReader.indexExists(ramDirectory) is reading fileMap to
> look for indexes, causing the NPE.

In fact the original user's list email that started this bug was also
due to RAMDirectory setting its fileMap to null, but in that case, it
was via IndexWriter so detecting that IndexWriter is closed would
prevent that one.

In this case the developer is using a RAMDirectory directly.

I think this is an example where "nulling things out on close" leads
to developer confusion.  Previously RAMDirectory functioned fine after
being closed(); now, it throws a hard to understand (unless you are
familiar w/ Lucene's sources & what specifically we changed in 2.1)
NPE.

I think we should fix this?

Since RAMDir's public methods are fairly hot (eg heavily used building
single-doc RAM segment), we can use Hoss's neat approach and
specifically catch the NPE and rethrow as an AlreadyClosedException?

I don't mind if the "after close semantics" is "it works just like it
did when it was open" (ie, close is a no-op).  I also don't mind if
you get a "fail-fast" quick AlreadyClosedException.  But I think
anything in between (NPE or other undefined, intermittant exceptions)
only confuses our developers.

Looking at FSDirectory, it continues to work fine after close with the
one spooky exception that it may have been removed from the
DIRECTORIES hashtable, which means if you then open the same canonical
path again you get a different FSDirectory instance.  The comment
states "this permits synchronization on directories", but I don't see
where in Lucene we are relying on this?  Ie, what could break if a
user keeps using a closed FSDirectory thus possibly having more than
one FSDirectory instance for a given canonical path?


> 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, LUCENE-818.take3.patch, LUCENE-818.take4.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