commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston (JIRA)" <>
Subject [jira] Closed: (NET-30) FTPClient deals badly with adverse network conditions
Date Wed, 20 Dec 2006 10:16:22 GMT
     [ ]

Rory Winston closed NET-30.

> FTPClient deals badly with adverse network conditions
> -----------------------------------------------------
>                 Key: NET-30
>                 URL:
>             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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message