Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3F7192EA.8050908@detego-software.de>
Date: Wed, 24 Sep 2003 14:49:46 +0200
From: Christoph Goller <goller@detego-software.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Subject: Re: FSInputStream strangeness
References: <3F6CC0F5.10200@earthlink.net> <3F70A0CE.2080405@lucene.com>
In-Reply-To: <3F70A0CE.2080405@lucene.com>
Content-Type: multipart/mixed;
 boundary="------------070306090509060603040705"

--------------070306090509060603040705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


Doug Cutting schrieb:
> Dmitry Serebrennikov wrote:
> 
>> There are two such issues I found so far. Has anyone seen this before? 
>> Is this intentional? Does some functionality depend on these?
> 
> 
> I don't think they're intentional, and nothing should depend on them.
> 
>> - seek() calls with negative arguments or with arguments greater than 
>> the file length appear to succeed
>> - reading from a stream after a call to close() also succeeds (at 
>> least some times).
>>
>> I think both of these are related to buffering that is performed by 
>> FSInputStream. Calls to close() do not clear this buffer and 
>> subsequent read calls that do not require a refill of the buffer are 
>> allowed to succeed.
> 

Closing a FSInputStream only closes the underlying file if the FSInputStream
is not a clone. If close is called for a clone it does nothing and the
respective FSInputStream still works. Calls to readByte() are still possible
even outside the buffer. I think this behavior of close() is acceptable
since the only thing close really has to do is free resources if possible.
However, I found a place where the code currently relies on this behavior.
DateFilter closes a TermDocs in bits(reader) and uses it again later. The
code only works since SegmentTermReader keeps a copy of freqStream and thus
SegmentTermDocs cannot close the underlying file, it only has control on a
clone of freqStream.

I attach a patch for DateFilter that moves the termDocs.close() to the right
place. Since this patch does not solve any bug, I do not have any new test.
I tried TestDateFilter with my changes and it still works.

Christoph

-- 
*****************************************************************
* Dr. Christoph Goller       Tel.:   +49 89 203 45734           *
* Detego Software GmbH       Mobile: +49 179 1128469            *
* Keuslinstr. 13             Fax.:   +49 721 151516176          *
* 80798 M�nchen, Germany     Email:  goller@detego-software.de  *
*****************************************************************

--------------070306090509060603040705
Content-Type: text/plain;
 name="DateFilterPatch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="DateFilterPatch.txt"

Index: DateFilter.java
===================================================================
RCS file: /home/cvspublic/jakarta-lucene/src/java/org/apache/lucene/search/DateFilter.java,v
retrieving revision 1.8
diff -u -r1.8 DateFilter.java
--- DateFilter.java	13 Sep 2003 23:40:29 -0000	1.8
+++ DateFilter.java	24 Sep 2003 12:45:06 -0000
@@ -157,18 +157,15 @@
       Term stop = new Term(field, end);
       while (enumerator.term().compareTo(stop) <= 0) {
         termDocs.seek(enumerator.term());
-        try {
-          while (termDocs.next()) {
-            bits.set(termDocs.doc());
-          }
-        } finally {
-          termDocs.close();
+        while (termDocs.next()) {
+          bits.set(termDocs.doc());
         }
         if (!enumerator.next()) {
           break;
         }
       }
     } finally {
+      termDocs.close();
       enumerator.close();
     }
     return bits;

--------------070306090509060603040705--