commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] Closed: (NET-30) FTPClient deals badly with adverse network conditions
Date Thu, 20 Sep 2007 05:26:14 GMT

     [ https://issues.apache.org/jira/browse/NET-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Henri Yandell closed NET-30.
----------------------------

    Resolution: Fixed

Reclosing so it gets marked as Fixed. Jira migration bug.

> FTPClient deals badly with adverse network conditions
> -----------------------------------------------------
>
>                 Key: NET-30
>                 URL: https://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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message