Hi Andy,
I don't think it's conceptually clean to close the file object before
the stream is closed, it's very counterintuitive. I think the stream
must be closed first and than the file object. The close on the stream means
the transfer is finished, the close on the file object means you're done with
it altogether (in theory releasing it to an object pool or something similar).
In the handling you propose the exceptions are ignored anyway
(IOUtils.close(FileObject)) so it does not resolve the need to inform the FTP
client that the file transfer was not successful.
I do think that a close on FileObject is necessary but I don't think it is a
solution to my problem...
I don't quite follow your explanation of the assembly-line since I'm new here.
In my view the outputstream is written and closed in the context of the STOR
operation using a particular FileObject. If the close on the stream fails, the
exception should be caught and an error code should be returned to the client.
Likewise, if the close on the FileObject fails an error should be returned to
the client too.
If you don't want to be bothered by exceptions on close I think it should be
the responsibility of the FileObject to muffle them; e.g. by wrapping the
OutputStream and ignore the exceptions on close there. In the current situation
the STOR command is explicitly killing all options to signal something went
wrong.
Frank
> Date: Wed, 7 May 2008 21:18:14 -0600
> From: [EMAIL PROTECTED]
> To: dev@mina.apache.org
> Subject: Re: (FTPSERVER-119) STOR command should not eat exceptions when
> closing stream
>
> Frank,
>
> What should probably happen is that the FileObject.close() should be
> called first, this then gives you the opportunity to close the stream
> and handle the errors. The outStream close() would be called anyway,
> because not everyone may want to handle their own close() so it insures
> the stream is closed.
>
> In the STOR command
>
> ...
> finally {
>
> // provide an opportunity for the FileObject to handle close
> IoUtils.close(file);
>
> // close the stream, it may have been previously closed, make sure
> IoUtils.close(outStream);
> }
>
> In the FileObject
>
> public void close() {
> // close the stream(s) or raf
>
> // do some other clean-up
> }
>
> This implies some changes in the FileObject issuance of the
> createOutputStream() and createInputStream() if you wish to handle the
> close on the stream(s). Or at least a change for the write-stream in any
> case.
>
> Once an operation [close() for example] leaves the FileObject, ie, it's
> at the Command-level, the command-level does not know one file object
> from another, nor if one FileObject is suppose to be handled
> differently, it's just doing an assembly-line operation.
>
> Does the above make sense on why a FileObject.close() was proposed?
> Trying to handle individual FileObject tasks at the command level just
> causes the "assembly-line" to slow down, and possibly break. Far better
> to call the FileObject and let it deal with it's needs.
>
> From your comments [excellent feedback], what should be done at the
> command-level is call the FileObject.close() first, then the stream close.
>
> Andy Thomson
>
> Frank van der Kleij wrote:
> > Thanks for commenting on the issue.
> >
> > The close on the file object seems a good idea in general but for me it
> > won't do the trick. The Apache VFS API does provide for close operations
> > but they serve a slightly different purpose.
> >
> > VFS uses a stream based API to write; three objects are involved, a
> > FileObject, a FileContent and an OutputStream ( to write you'd have to do
> > fileObject.getFileContent().getOutputStream() ). Close on FileObject means
> > you're done treating the file, which is different from meaning that you're
> > done writing to it. The same goes for close on FileContent, which is
> > supposed to release all resources and closes InputStreams as well. Only
> > close on the OutputStream only means that all data is transferred.
> >
> > For information, internally in VFS operations, e.g. on a copy operation,
> > the close is only called on the outputstream too.
> >
> > My point is that a close on the FileObject is not what I'm looking for; it
> > is rather the handling of exceptions on close of the stream that concern
> > me.
> >
> > I doubt it is really necessary to ignore exceptions on the close of the
> > stream. I can imagine it was done because the close is called in a finally
> > block and handling exceptions there is rather ugly.
> >
> > By doing the close before the finally the exceptions can be handled
> > normally. It would do a double close on the same stream, but streams are
> > supposed to support that kind of thing.
> >
> > Best regards,
> > Frank
> >
> >
> > _________________________________________________________________
> > Express yourself instantly with MSN Messenger! Download today it's FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
