When do SharedInputStreams get closed?

[Boris Burtin-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I have my own implementation of SharedInputStream, which accesses a file on disk with RandomAccessFile.  When newStream() is called, I create a new stream object that uses the same RandomAccessFile, and add it to a Set for reference counting.  When close() is called, I remove it from the Set.  When the last stream in the stream group is closed, I close the RandomAccessFile.

After parsing a MimeMessage, I see a bunch of instances of my SharedInputStream that weren't closed.  As a result, my file descriptor stays open indefinitely.  Is there an API call that I should make to close the streams?  The only code I found that closes MimeBodyPart.contentStream is updateHeaders().

Thanks in advance,

Boris

=========================================================================== To unsubscribe, send email to listserv@... and include in the body of the message "signoff JAVAMAIL-INTEREST". For general help, send email to listserv@... and include in the body of the message "help".

[Bill Shannon]

Boris Burtin wrote:

> I have my own implementation of SharedInputStream, which accesses a file
> on disk with RandomAccessFile.  When newStream() is called, I create a
> new stream object that uses the same RandomAccessFile, and add it to a
> Set for reference counting.  When close() is called, I remove it from
> the Set.  When the last stream in the stream group is closed, I close
> the RandomAccessFile.
>
> After parsing a MimeMessage, I see a bunch of instances of my
> SharedInputStream that weren't closed.  As a result, my file descriptor
> stays open indefinitely.  Is there an API call that I should make to
> close the streams?  The only code I found that closes
> MimeBodyPart.contentStream is updateHeaders().

When the original SharedInputStream is closed, the sub-streams should be
closed.  There may be bugs where the sub-streams aren't closed independently
by JavaMail when they should be.  But since you create the top level stream
to pass to MimeMessage for parsing, you should be able to close it.

Have you looked at SharedFileInputStream?

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Boris Burtin-2]

Aha, thanks for the tip.  I may be able to dump my custom code and just use SharedFileInputStream as is, if it shares file descriptors between substreams.  Did substreams always share the file descriptor?  Maybe I misread the code back in the 1.3 days.

One followup question: if I close the top-level stream, does it mean that I'm no longer able to call Part.getInputStream()?  I want to cache the MimeMessage object to avoid reparsing later, but also conserve resources by closing the file descriptor until the next time that the message content is accessed.

----- "Bill Shannon" <bill.shannon@...> wrote:

> Boris Burtin wrote:
> > I have my own implementation of SharedInputStream, which accesses a
> file
> > on disk with RandomAccessFile.  When newStream() is called, I create
> a
> > new stream object that uses the same RandomAccessFile, and add it to
> a
> > Set for reference counting.  When close() is called, I remove it
> from
> > the Set.  When the last stream in the stream group is closed, I
> close
> > the RandomAccessFile.
> >
> > After parsing a MimeMessage, I see a bunch of instances of my
> > SharedInputStream that weren't closed.  As a result, my file
> descriptor
> > stays open indefinitely.  Is there an API call that I should make to
>
> > close the streams?  The only code I found that closes
> > MimeBodyPart.contentStream is updateHeaders().
>
> When the original SharedInputStream is closed, the sub-streams should
> be
> closed.  There may be bugs where the sub-streams aren't closed
> independently
> by JavaMail when they should be.  But since you create the top level
> stream
> to pass to MimeMessage for parsing, you should be able to close it.
>
> Have you looked at SharedFileInputStream?
>
> ===========================================================================
> To unsubscribe, send email to listserv@... and include in the
> body
> of the message "signoff JAVAMAIL-INTEREST".  For general help, send
> email to
> listserv@... and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".

[Bill Shannon]

Boris Burtin wrote:
> Aha, thanks for the tip.  I may be able to dump my custom code and just use
> SharedFileInputStream as is, if it shares file descriptors between
> substreams.  Did substreams always share the file descriptor?  Maybe I
> misread the code back in the 1.3 days.

Yes, the file is opened once.

> One followup question: if I close the top-level stream, does it mean that I'm
> no longer able to call Part.getInputStream()?  I want to cache the
> MimeMessage object to avoid reparsing later, but also conserve resources by
> closing the file descriptor until the next time that the message content is
> accessed.

Yes, closing the top level stream forces the others to close.  If you want
them to remain open, you need to manage the top level stream explicitly.

===========================================================================
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JAVAMAIL-INTEREST".  For general help, send email to
listserv@... and include in the body of the message "help".