java - commons net ftp deadlock? -

I have a procedure that is supposed to file the file at a remote location every 5 minutes.

It seems that has been stuck for several hours and he is not sending the file.

I have dumped a thread to see what's going on and this is the status of my thread:

  "SPPersister" prio = 6 tid = 0x03782400 nid = 0x16c4 Runnable [0x0468f000..0x0468fd14] java.lang.Thread.State: java.net.SocketInputStream.socketRead0 (native resident method) runnable on java.net.SocketInputStream.read (unknown source) sun.nio.cs.StreamDecoder.read But at sun.nio.cs.StreamDecoder.implRead on sun.nio.cs.StreamDecoder.readBytes (unknown source) (unknown source) - lock & lt; 0x239ebea0 & gt; (A java.io.InputStreamReader) java.io.buffferedReader.readLine at java.io.buffferedReader.fill on java.io.InputStreamReader.read (unknown source) (unknown source) - stopped & Lt; 0x239ebea0 & gt; (A java.io.InputStreamReader) at java.io.buffferedReader.readLine (Unknown Source) at org.apache.commons.net.ftp.FTP .__ getReply (FTP.java294) org.apache.commons.net . Ftp.FTP._connectAction_ (FTP.java:364) org.apache.commons.net.ftp.FTPClient._connectAction_ (FTPClient.java )40.organize.acache.commons.net.SocketClient.connect (at 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); // and & lt; - Stuck here client.setDataTimeout (20000); Client.setSoTimeout (20000); Client.login (user, pass); Client.changeWorkingDirectory (dir);  

Should the connection attempt end within 10 seconds?

Yes, no more.

The connect must have ended within ten seconds, assuming that the connecting is not working, although the connector may have worked, and now it is trying to read from the data socket, The way to get the initial FTP hello sequence is likely [1] Actually, considering that, where your stacktrace is trapped, that is what it is doing.

You can try to set before connecting, in this way it may fail in your failed manner. If this does not work, then you will need the most, almost certainly the issue you are seeing.

[1] According to RFC 959:

An important group connection of informative answers is good luck. Under normal circumstances, a Connection 220 response will "wait for input", when the connection will be completed. The user must wait for this greeting message before sending any order. If the server is still unable to accept the input, then the 120 "expected delays" answer should be sent immediately and answer 220 when ready. Then the user will know that there is no delay.

This is the reason that the FTP client class is waiting for input from the foreign side.