Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <151695103.1243780387406.JavaMail.jira@brutus>
Date: Sun, 31 May 2009 07:33:07 -0700 (PDT)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1658) Absorb NIOFSDirectory into
 FSDirectory
In-Reply-To: <1868008588.1243181445652.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-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714866#action_12714866 ] 

Uwe Schindler commented on LUCENE-1658:
---------------------------------------

bq. Yikes - you mean there's a pre-existing issue with the fix in LUCENE-1453, before this issue was committed? I agree that code is very spooky, and I'll be very happy once we remove (in 3.0) the cache/refCounting done by FSDir.getDirectory....

The problem is not really the caching/refcounting. The reopen code sometimes seems to close the directory, even than it should not. There is no difference if the directory is cached (and the number of opens() is tracked by refCount) or standalone. The problem is that SegmentReader's readNorms() hits AlreadyClosedException then...

The interesting thing is that ou can more easy reproduce it with stand-alone dirs (because I removed the caching, you know). The 1453 fix is also needed for stand-alone dirs (so everytime codeDirectory=true), because, if they are closed during an error/whatever, the same happens. It does not happen so easy with cached dirs, because the old reader is normally closed after the new reopened one, so during the reopen, the refcount is big enough.

In my opinion, the only good solution is to remove the whole directory-close stuff from readers/writers in 3.0, as said before. And this can be done by removing the string-type dir arguments from Reader/Writer. And: As these use currently FSDir.getDirectory() they should be changed to FSDir.open() or deprecated, I tend to the last one.

> Absorb NIOFSDirectory into FSDirectory
> --------------------------------------
>
>                 Key: LUCENE-1658
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1658
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Store
>            Reporter: Michael McCandless
>            Assignee: Uwe Schindler
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: LUCENE-1658-take2.patch, LUCENE-1658-take2.patch, LUCENE-1658.patch, LUCENE-1658.patch, LUCENE-1658.patch
>
>
> I think whether one uses java.io.* vs java.nio.* or eventually
> java.nio2.*, or some other means, is an under-the-hood implementation
> detail of FSDirectory and doesn't merit a whole separate class.
> I think FSDirectory should be the core class one uses when one's index
> is in the filesystem.
> So, I'd like to deprecate NIOFSDirectory, absorbing it into
> FSDirectory, and add a setting "useNIO" to FSDirectory.  It should
> default to "true" for non-Windows OSs, because it gives far better
> concurrent performance on all platforms but Windows (due to known Sun
> JRE issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734).

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