Hello together. I have a weird problem which unfortunately leads to production halts at two of our customers so I urge for a pointer in the right direction here.
My software periodically detects files on a FTP Server and downloads them. This works fine for some time but quite randomly, out of a suddin this loop starts to hang indefinitely until manually killed and restarted by the Administrator. I narrowed it down so far that I can say that the FTPClient.listFiles() method hangs and never returns. Here is what the ftp communication log says on a normal run: 2012-09-04T12:41:01.130Z DEBUG [location.FtpLocation.protocolCommandSent] Veribox A-Dateien: --> NOOP 2012-09-04T12:41:01.132Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 200 Command okay. 2012-09-04T12:41:01.132Z DEBUG [location.FtpLocation.protocolCommandSent] Veribox A-Dateien: --> PASV 2012-09-04T12:41:01.140Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 227 Entering Passive Mode (172,35,1,12,7,70 ) 2012-09-04T12:41:01.141Z DEBUG [location.FtpLocation.protocolCommandSent] Veribox A-Dateien: --> LIST * 2012-09-04T12:41:01.146Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 150 Opening ASCII mode data connection for /bin/ls. 2012-09-04T12:41:01.186Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 226 Transfer complete. 117 bytes transferre d. 7,14 KB/sec. And here is what it says the moment it hangs up: 2012-09-04T12:41:51.196Z DEBUG [location.FtpLocation.protocolCommandSent] Veribox A-Dateien: --> NOOP 2012-09-04T12:41:51.197Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 200 Command okay. 2012-09-04T12:41:51.198Z DEBUG [location.FtpLocation.protocolCommandSent] Veribox A-Dateien: --> PASV 2012-09-04T12:41:51.204Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 227 Entering Passive Mode (172,35,1,12,7,71 ) 2012-09-04T12:41:51.205Z DEBUG [location.FtpLocation.protocolCommandSent] Veribox A-Dateien: --> LIST * 2012-09-04T12:41:51.211Z DEBUG [location.FtpLocation.protocolReplyReceived] Veribox A-Dateien: <-- 150 Opening ASCII mode data connection for /bin/ls. As you can see, the server answers that it's opening an ascii mode data connection but then nothing seems to happen. This is what netstat -np says: tcp 91 0 172.30.3.21:39009 172.35.1.12:2730 CLOSE_WAIT 24094/java tcp 0 0 172.30.3.21:45273 172.35.1.12:1863 ESTABLISHED 24094/java tcp 0 0 172.30.3.21:56584 172.35.1.12:2299 ESTABLISHED 24094/java tcp 0 0 172.30.3.21:53582 172.35.1.12:2730 ESTABLISHED 24094/java tcp 0 0 172.30.3.21:57945 172.35.1.12:2730 ESTABLISHED 24094/java tcp 95 0 172.30.3.21:39010 172.35.1.12:2730 CLOSE_WAIT 24094/java 2730 is the control port of the ftp server, 2299, 1863 are data connections. Note the non-empty Send-Q for the CLOSE_WAIT connections. The issue I have here seems to be relatively independent of everything I can come up with. We have this problem in both linux (SuSE 11.4 64bit) and Windows XP, The FTP server being once a Serv-U under Windows 2003 Standard and vsftp under linux. The java virtual machine is openjdk under linux and sun java 6 under windows. As far as I can see, no proxies or firewalls are in the way on either of the customers systems. I tested with both commons-net 2.0 and 3.1 with no difference in result. Did anyone on this list ever encounter an issue like this before and is there a way to circumvent this stalling of the listFiles() call? Kind regards, Johannes Frank -------------------------------------------------------------------------------------------------------------------------------------------- Johannes Frank - KISTERS AG - Charlottenburger Allee 5 - 52068 Aachen - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 241 9671 -0 | Fax: +49 241 9671 -555 | E-Mail: [email protected] | WWW: -------------------------------------------------------------------------------------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
