commons-user mailing list archives

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

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
itself.
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 <413C7ACC.3070207@picturesafe.de>, Marco Jacob writes:
> 
>>  FTPClient.retrieveFile(String, OutputStream)
>>
>>flushes the OutputStream after each time it calls write(byte[], int, int)=
>>=2E
> 
> ...
> 
>>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 java.io 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 java.io 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
GERMANY

Fon: +49 511 - 856 20 54
Fax: +49 511 - 856 20 10
mailto:mjacob@picturesafe.de


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message