公共网络ftp僵局? [英] commons net ftp deadlock?

问题描述

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

I have a process that is supposed to ftp a file to a remote location every 5 minutes.

它似乎卡住了好几个小时，没有发送文件.

It seems to have become stuck for a number of hours and hasn't been sending files.

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

I took a thread dump to see what was going on and this is the state of my thread:

"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)
        ...

我使用以下代码进行连接:

I am using the following code to connect:

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 秒内超时吗?

Shouldn't the connection attempt have timed out within 10 seconds?

推荐答案

是，也不是.

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

The connect will have timed out within ten seconds, assuming that the connect did not work, however the connect probably did work, and now it is trying to read data from the socket, most likely to get the initial FTP helo sequence out of the way[1]. Indeed, looking at the javadoc for connectAction(), which is where your stacktrace is stuck, that is exactly what it is doing.

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

You could try setting the data timeout before you call connect, that way it might actually fail in the way that you expect. If this doesn't work, you will most likely need to raise a bug with apache-commons. This bug is almost certainly the issue that you are seeing.

[1] 根据 RFC959:

[1] According to RFC959:

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

One important group of informational replies is the connection greetings. Under normal circumstances, a server will send a 220 reply, "awaiting input", when the connection is completed. The user should wait for this greeting message before sending any commands. If the server is unable to accept input right away, a 120 "expected delay" reply should be sent immediately and a 220 reply when ready. The user will then know not to hang up if there is a delay.

这就是 FTPClient 类等待外部输入的原因.

That is why the FTPClient class is awaiting input from the foreign side.

这篇关于公共网络ftp僵局?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！