Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <2093514967.1244413687447.JavaMail.jira@brutus>
Date: Sun, 7 Jun 2009 15:28:07 -0700 (PDT)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Reopened: (LUCENE-1453) When reopen returns a new
 IndexReader, both IndexReaders may now control the lifecycle of the
 underlying Directory which is managed by reference counting
In-Reply-To: <614971342.1226783024383.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-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler reopened LUCENE-1453:
-----------------------------------


After some testing, I found out, that this issue is not fixed. The test "TestIndexReaderReopen" fails very often, if all occurences of FSDirectory.getDirectory() are replaced by FSDirectory.open() in IndexReader/IndexWriter and DirectoryReader.
open() returns non refcounting single-use directorys that can be closed only one time. If readers on top of this (using the now-deprecated File/String IndexReader.open()) are reopened the directories are sometimes closed false.
I was hoping, LUCENE-1651 fixes this, but this is not so.

There are two possibilities to fix this:
For both, the first step is to remove the whole closeDir stuff from all IndexReaders and do not close it from within indexReader.
Then there are two solutions:
- As FSDir.open() only returns subclasses of FSDir that have a no-op close() method, no closing is required. So we can just leave them open
- Another possibility is to wrap all readers opened by IR.open() with File/String param by an (deprecated, package private) FilterIndexReader that handles closing the directory in close() and reopen() in a proper way. This is much simplier than doing it inside the DirectoryReader reopen stuff. The small overhead in passing through FilterIndexReader only affects people using the deprecated File/String open() methods. Users, directly using FSDir & Co. have no slowdown.

> When reopen returns a new IndexReader, both IndexReaders may now control the lifecycle of the underlying Directory which is managed by reference counting
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1453
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1453
>             Project: Lucene - Java
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Mark Miller
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4.1, 2.9
>
>         Attachments: LUCENE-1453.patch, LUCENE-1453.patch, LUCENE-1453.patch
>
>
> Rough summary. Basically, FSDirectory tracks references to FSDirectory and when IndexReader.reopen shares a Directory with a created IndexReader and closeDirectory is true, FSDirectory's ref management will see two decrements for one increment. You can end up getting an AlreadyClosed exception on the Directory when the IndexReader is open.
> I have a test I'll put up. A solution seems fairly straightforward (at least in what needs to be accomplished).

-- 
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