DO NOT REPLY [Bug 31122] New: - FTPClient deals badly with adverse network conditions

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31122>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31122

FTPClient deals badly with adverse network conditions

           Summary: FTPClient deals badly with adverse network conditions
           Product: Commons
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Net
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: apache@misc.lka.org.lu


We are attempting to use the FTPClient included in commons-net 1.2.2 to write 
an application which has to deal with various outages: 
- connection closed by server, without 421 warning 
- connection frozen 
- server temporarily unreachable 
- ... 
 
However, it appears that in most of these cases, FTPClient becomes easily 
confused: 
- If the connection is closed without warning, FTPClient doesn't notice at 
first: ftp.isConnected() still returns true. However, when attempting to use 
such a closed connection, we do get the correct exception 
(FTPConnectionClosedException), at least most of the time (occasionnally we do 
get various SocketExceptions instead) 
- If the ftp server doesn't respond in time, FTPClient hangs forever, even 
after the ftp server responds eventually 
- If setSoTimeout is set, and if the server doesn't respond, the following 
behaviour happens: 
** if the server becomes responsive again before the timeout happens, the 
client hangs until the timeout then receives SocketTimeoutException exception. 
We would prefer if the client just continued normally (as the server did 
respond before timeout) 
** if on the other hand the server does not become responsive when the timeout 
happens, the client won't get any exception when timeout expires. Instead it 
will just hang. As soon as the server gets responsive again (i.e. _after_ the 
timeout had expired), the client immediately get the exception. We would prefer 
if the client got the exception at the timeout, rather than long afterwards.

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