5

我有一个应该每 5 分钟将文件 ftp 到远程位置的进程。

它似乎已经卡住了几个小时并且没有发送文件。

我进行了线程转储以查看发生了什么，这是我线程的状态：

"SPPersister" prio=6 tid=0x03782400 nid=0x16c4 runnable [0x0468f000..0x0468fd14]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(Unknown Source)
        at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
        at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
        at sun.nio.cs.StreamDecoder.read(Unknown Source)
        - locked <0x239ebea0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(Unknown Source)
        at java.io.BufferedReader.fill(Unknown Source)
        at java.io.BufferedReader.readLine(Unknown Source)
        - locked <0x239ebea0> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(Unknown Source)
        at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:294)
        at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:364)
        at org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:540)
        at org.apache.commons.net.SocketClient.connect(SocketClient.java:178)
        at org.apache.commons.net.SocketClient.connect(SocketClient.java:268)
        ...

我正在使用以下代码进行连接：

FTPClient client = new FTPClient();
client.setConnectTimeout(10000);
client.connect(host); // <-- stuck here
client.setDataTimeout(20000);
client.setSoTimeout(20000);
client.login(user, pass);
client.changeWorkingDirectory(dir);

连接尝试不应该在 10 秒内超时吗？

4

2 回答 2

4

是的，没有。

假设连接没有工作，连接将在十秒内超时，但是连接可能确实工作，现在它正在尝试从套接字读取数据，最有可能让初始的 FTP helo 序列不碍事[1]。确实，查看connectAction ()的 javadoc，这是您的堆栈跟踪卡住的地方，这正是它正在做的事情。

您可以在调用 connect 之前尝试设置数据超时，这样它实际上可能会以您期望的方式失败。如果这不起作用，您很可能需要使用 apache-commons 提出错误。这个错误几乎肯定是您看到的问题。

[1] 根据 RFC959：

一组重要的信息回复是连接问候。一般情况下，连接完成后，服务器会发送一个 220 回复，“等待输入”。用户在发送任何命令之前应等待此问候消息。如果服务器无法立即接受输入，则应立即发送 120“预期延迟”回复，并在准备好时发送 220 回复。然后，如果有延迟，用户将知道不要挂断。

这就是 FTPClient 类等待来自外部的输入的原因。

于 2010-01-24T00:38:00.890 回答
2

我们有一些 java 正在尝试从设备进行 FTP，并且使用 commons-net/ftp 会莫名其妙地挂起。就像你所看到的一样。经过大量搜索，我在某处发现了一个错误报告，表明这是 commons-net/ftp 的一个缺陷。当您等待响应并且网络出现故障（我们有不稳定的无线）时，就会出现该缺陷。一旦发生这种情况，它就会陷入永远不会回来的等待。

不幸的是，我们找到的解决方案是使用不同的库。那里有很多，但这是我们使用的。 http://www.enterprisedt.com/products/edtftpj/overview.html

于 2010-01-24T00:53:02.457 回答