commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: Flush by net.ftp.FTPClient.retrieveFile(String, OutputStream)
Date Tue, 07 Sep 2004 18:34:48 GMT

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



---------------------------------------------------------------------
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