lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Goller <>
Subject Re: FSInputStream strangeness
Date Wed, 24 Sep 2003 12:49:46 GMT

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.


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

View raw message