lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <>
Subject Re: IndexInput not being closed
Date Wed, 14 Oct 2009 01:44:21 GMT
It's OK... IndexInputs have never all been closed.  IndexInput clones
don't need to be closed as they share the same resources with the
original.  They are also often cached in thread locals.


On Tue, Oct 13, 2009 at 9:25 PM, Gui Forget <> wrote:
> Hello,
> This is my first email to this list so I hope I posted it to the right list.
> I'm in the process of upgrading my web application from Lucene 2.0 to Lucene
> 2.4.1.  Things went pretty smoothly but I noticed that some IndexInput were
> created via cloning but were never closed.
> The trace of the creation is as follow:
> at
> org.apache.lucene.index.CompoundFileReader$CSIndexInput.clone(
> at org.apache.lucene.index.SegmentTermDocs.skipTo(
> at
> at$TermWeight.explain(
> at
> at
> at
> Looking at the source of MultiLevelSkipListReader it is pretty clear that
> the IndexInput which is stored in the first position in the array skipStream
>  is never closed. So either SegmentTermDocs should not clone the IndexInput
> that it passes to the skipListReader or the skipListReader should make sure
> it closes it when close is being called.
> Linked to that issue I have 2 questions:
> - could someone explain to me what is the impact of this bug? How bad is it?
> - in Lucene 2.4.1, I noticed that these IndexInput objects are cloned a lot
> (but like really a lot). This was not the case in 2.0. I'm not very familiar
> with the very low level infrastructure of Lucene, but can someone explain to
> me why this was changed?I'm a bit worried of seeing so many objects created
> even if it's for a very short period of time.
> Thank you.
> Gui

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message