[jira] Closed: (NET-30) FTPClient deals badly with adverse network conditions

["Rory Winston (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/NET-30?page=all ]

Rory Winston closed NET-30.
---------------------------


> FTPClient deals badly with adverse network conditions
> -----------------------------------------------------
>
>                 Key: NET-30
>                 URL: http://issues.apache.org/jira/browse/NET-30
>             Project: Commons Net
>          Issue Type: Bug
>         Environment: Operating System: Linux
> Platform: PC
>            Reporter: Alain Knaff
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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