commons net ftp blockiert?

Question

Ich habe einen Prozess, der alle 5 Minuten eine Datei per FTP an einen entfernten Ort übertragen soll.

Es scheint seit einigen Stunden festzustecken und sendet keine Dateien mehr.

Ich habe einen Thread-Dump gemacht, um zu sehen, was los ist, und das ist der Zustand meines Threads:

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

Ich verwende den folgenden Code für die Verbindung:

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);

Hätte der Verbindungsversuch nicht innerhalb von 10 Sekunden abgebrochen werden müssen?

Answer 1

Ja und nein.

Die Verbindung wird innerhalb von zehn Sekunden abgebrochen sein, wenn man davon ausgeht, dass die Verbindung nicht funktioniert hat. Wahrscheinlich hat die Verbindung jedoch funktioniert, und jetzt wird versucht, Daten aus dem Socket zu lesen, höchstwahrscheinlich, um die anfängliche FTP-Helo-Sequenz aus dem Weg zu schaffen[1]. In der Tat, ein Blick auf [die Javadoc für connectAction ()](http://commons.apache.org/net/api/org/apache/commons/net/ftp/FTPClient.html#_connectAction_()) und genau dort bleibt Ihr Stacktrace hängen, das ist genau das, was er tut.

Sie könnten versuchen, die Einstellung die Datenzeitüberschreitung bevor Sie connect aufrufen, denn dann könnte es tatsächlich so scheitern, wie Sie es erwarten. Wenn dies nicht funktioniert, müssen Sie höchstwahrscheinlich einen Fehler bei apache-commons melden . Dieser Fehler ist mit ziemlicher Sicherheit das Problem, das Sie sehen.

[1] Gemäß RFC959:

Eine wichtige Gruppe von Informationsantworten sind die Verbindungs Grüße. Unter normalen Umständen sendet ein Server eine 220 Antwort, "awaiting input", wenn die Verbindung beendet ist. Der Benutzer sollte diese Begrüßungsnachricht abwarten, bevor er irgendwelche Befehle. Wenn 120 "erwartete Verzögerung" gesendet werden und eine 220 Antwort, wenn er bereit ist. Der Benutzer weiß dann, dass er nicht auflegen muss, wenn es eine Verzögerung eintritt.

Aus diesem Grund wartet die Klasse FTPClient auf Eingaben von der fremden Seite.

Answer 2

Wir hatten ein Java, das versuchte, FTP von einem Gerät aus zu nutzen, und es blieb unerklärlicherweise bei der Verwendung von commons-net/ftp hängen. Genau wie das, was Sie jetzt sehen. Nach langem Suchen habe ich irgendwo einen Fehlerbericht gefunden, der besagt, dass es sich um einen Fehler in commons-net/ftp handelt. Der Fehler tritt auf, wenn man auf eine Antwort wartet und das Netzwerk ausfällt (wir hatten ein schwaches WLAN). Sobald das passierte, geriet es in einen Wartezustand, der nie wiederkehrte.

Die Lösung, die wir gefunden haben, besteht leider darin, eine andere Bibliothek zu verwenden. Es gibt viele da draußen, aber dies ist die, die wir verwendet haben. http://www.enterprisedt.com/products/edtftpj/overview.html