commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31122] - FTPClient deals badly with adverse network conditions
Date Thu, 09 Sep 2004 20:22:16 GMT
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





------- Additional Comments From apache@misc.lka.org.lu  2004-09-09 20:22 -------
Indeed, if point #1 (ftp.isConnected()) is the intended behavior, and if #5 
(connect timeout) cannot be addressed in JDK 1.2, then the only action left is 
indeed #4, i.e. a documentation fix. 
 
Or maybe, it could be fixed in the code by testing __readIsWaiting in 
TelnetInputStream.run():  if __readIsWaiting is not set when the 
InterruptedIOException occurs, just loop around without storing it into 
__ioException. That way it would work both in __threaded and non-__threaded 
mode. The difficulty however for such a fix would be the border cases, such as 
for example the situation where a user-level read() happens when the timeout 
is already half expired, leaving only half to go. Maybe something could be 
done by recording the start times of run's read() and of the user-level 
read(), and dynamically adjusting the soTimeout?

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


Mime
View raw message