Hi Jukka,

For this typical try...finally code I suggest to use a pre-Java-7.0
workaround to make this behave more correct: If you do try...finally and
another Exception occurs on close() in the finally block, you lose the first
Exception. The new Java-7 try-with-resources block handles that
fantastically (it also records all exceptions happening during closing
inside the top-level exception). To achieve that with Java 5/Java 6 we added
a class called IOUtils to Lucene that emulates this with only few more
lines:

https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/src/java/org/apache
/lucene/util/IOUtils.java

Code examples are in Javadocs but look very similar to try-with-resources
(it mimics that without java syntax changes). The class also detects Java7
and records suppressed exceptions, otherwise ignores them completely (Java 7
support was added by me).

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]


> -----Original Message-----
> From: Jukka Zitting [mailto:[email protected]]
> Sent: Wednesday, August 31, 2011 6:43 PM
> To: [email protected]
> Subject: Re: Tika leaves files open
> 
> Hi,
> 
> On Tue, Aug 30, 2011 at 11:19 PM, Jukka Zitting <[email protected]>
> wrote:
> > Yes, I think you're right. I believe the problem here is the
> > openContainer field within TikaInputStream where the container-aware
> > type detection code stores the already opened container (in this case
> > an NPOIFSFileSystem object) to avoid having to duplicate the parsing
> > work. Unfortunately there's no mechanism (except garbage collection by
> > the JVM) by which the container object gets properly disposed when
> > it's no longer needed, and I believe this is what's preventing the
> > underlying temporary files from getting reclaimed.
> 
> Actually the problem was much simpler than that. Code within the
> ParserContainerExtractor class creates a new TikaInputStream for
processing
> an embedded resource, but then never closes that stream.
> This prevents the temporary file behind that stream from being removed on
> Windows.
> 
> See the attached patch for a quick draft of a fix.
> 
> BR,
> 
> Jukka Zitting

Reply via email to