commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Jacob <>
Subject Re: Flush by net.ftp.FTPClient.retrieveFile(String, OutputStream)
Date Wed, 08 Sep 2004 05:50:44 GMT

2. would be great. I don't know if other code maybe suffer from
not flushing the stream. Normally the caller is reponsible for
flushing and closing the OutputStream.
In my current case flushing _at the end_ would be no harm. But
it could harm if I'd like to stream direct to ServletOutput.
I don't really know what my colleagues will call this FTPUtil class
with. But I can write a workaround that is copying the stream
Maybe there can be an optional setting not to flush the stream?
However, a note that retrieveFile flushes the stream should be in
the javadoc comment of this method.

Daniel F. Savarese wrote:
> In message <>, Marco Jacob writes:
>>  FTPClient.retrieveFile(String, OutputStream)
>>flushes the OutputStream after each time it calls write(byte[], int, int)=
> ...
>>I think, FTPClient.retrieveFile(String, OutputStream) should never flush
>>or close() the given OutputStream. The calling method should do this.
>>However, can this be changed in the next release?
> There are three separate issues here.  The first two concern the flush
> issue and the third the close issue.
> 1. retrieveFile calls Util.copyStream as a convenience.  So it's not
>    retrieveFile that is doing the flushing.  It's a byproduct of the call.
>    Should retrieveFile call Util.copyStream?  Probably, because otherwise
>    we'd just have to write another stream copying utility function.
> 2. Util.copyStream flushes the output stream after every write.  Does it
>    have to do this?  It doesn't have to do this for retrieveFile, but
>    it does have to do it to support interactive sessions for other
>    protocols like telnet which would hang because classes would
>    hold onto their buffers.  At the very least, it's a holdover from
>    JDK 1.1 days when the call to flush was the only way to make some things
>    work.  Since not every caller of copyStream needs the flushing, an option
>    can be provided to disable it.  We can leave flushing as the default
>    to avoid breaking anything and add a new method with an extra argument
>    turning flushing on or off (the original method would call it with
>    flushing on).  FTPClient can then use this method with flushing turned
>    off.  However, the underlying OutputStream may wind up making its own
>    flush calls inside of write, so this may not completely resolve your
>    particular situation.
> 3. Should retrieveFile close the output stream?  No.  In fact, it does not.
>    Only the source is closed, which has to be done anyway because the
>    end of stream is reached.
> Historical note.  I didn't want there to be a retrieveFile or a storeFile
> method because I thought convenience methods should go into subclasses or
> wrappers.  retrieveFileStream and storeFileStream already provided the
> required primitive functionality.  But users really wanted retrieveFile
> and storeFile in FTPClient, so there you go.
> Anyway, if you think the solution in 2. is useful, we can  make the
> appropriate adjustments.  However, I have dim memory that there may
> be an issue with not flushing in storeFile.  We can put in flush
> before the close there just in case.  I think some classes
> in JDK 1.1 days may not have flushed buffered output on closing and
> there may have been incomplete data written.
> daniel

Marco Jacob
picturesafe GmbH
Software Development
Lüerstraße 3
D-30175 Hannover

Fon: +49 511 - 856 20 54
Fax: +49 511 - 856 20 10

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

View raw message