Joe Hammerbacher created NET-510:
------------------------------------
Summary: FTPSClient.storeFile() hangs indefinitely if network
connection fails
Key: NET-510
URL: https://issues.apache.org/jira/browse/NET-510
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.3
Environment: Java 7, CentOS 6.4, commons.net 3.3
Reporter: Joe Hammerbacher
Priority: Blocker
Background:
I'm attempting to add some level of fault tolerance to an application that uses
FTPSClient to transfer files. If the connection between the client and server
fails, I'd like to capture the produced exception/return code, log the details,
and attempt to reconnect/retry the transfer.
What works:
The retrieveFile() method. If the connection fails, (i.e. I disable the
server's public interface), I receive a CopyStreamException caused by a
SocketTimeoutException after the amount of time I specified as the timeout.
Which makes sense if SO_TIMEOUT is getting set correctly...
>From the Javadocs:
"Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With
this option set to a non-zero timeout, a read() call on the InputStream
associated with this Socket will block for only this amount of time. If the
timeout expires, a java.net.SocketTimeoutException is raised, though the Socket
is still valid. The option must be enabled prior to entering the blocking
operation to have effect. The timeout must be > 0. A timeout of zero is
interpreted as an infinite timeout."
What doesn't work (as expected):
The storeFile() method. If I initiate a transfer via storeFile() and disable
the NIC on the server, the storeFile() method blocks/hangs indefinitely without
throwing any exceptions. I think that this is the result of nothing listening
on the DataSocket, which makes sense because I don't think there is anything
being sent back to the client over the DataSocket.
So, it doesn't appear to be possible for the write() to ever timeout if the
connection fails.
Am I missing something?
Thanks,
Joe
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
