mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From seventy boy <seventy...@virgilio.it>
Subject FTP SERVER : more fileoutputstream on the same file?
Date Wed, 25 Sep 2013 12:17:22 GMT
hello,
i'm confused trying to understand what happens server side when a FTP 
client restore a previous interrupted upload
consider the following scenario:
Client side:

 1. when trasferring bytes, an I/O exception occurs.
 2.   the client closes the FTP session, starts a new one,  issues a
    REST ( or SIZE) command, then a STORE.

what happens server side?
apache FTP server detect the I/O exception, sends the reply to the 
client, then attempt to close the file outputstream previously opened ( 
as seen in REST command implementation ?).
at the same time a new FTP session,following the above commands issued 
by the client,is allowed to create a new fileoutputstream object on the 
same file (as i saw in nativeFTPFile class), thus /*r*//*esulting in 
more fileoutputstream objects on the same file *//*?*/
this can happen because the fileOutStream.close() method can takes up to 
10 seconds in my esperience. My goal is avoid more fileOutputStream open 
concurrently on the same file (  the class java.io.FileOutputStream does 
not assure thread safety for file access), assuring so more safety and 
consistency.

if the client attempt to restart a previously interrumpted upload in the 
same FTP session,  the above situation  cannot take place because the 
execute command method  is inside a synchronized(session) block  in the 
DefaultFTPHandler class ( messageReceived method), so any following 
command can be performed only after the previously one is completed.  is 
It right?
i'd apprecciate your answer to clarify the correct mechanism of server 
side handling of restoring interrupted uploads and if provided a 
locking  file framework.
sorry if any mistake or missunderstanding in my request.
thanks in advance.
Ivo

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message