Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
3.3k views
in .NET FTP by (160 points)
On a regular basis, but not always i see an exception occuring when i call Close on SecureFTPConnection.

Below is the stack trace:

EnterpriseDT.Net.Ftp.FTPException: Data connection already open; transfer starting. (code=125)
at EnterpriseDT.Net.Ftp.FTPControlSocket.ValidateReply(FTPReply reply, String[] expectedReplyCodes)
at EnterpriseDT.Net.Ftp.FTPClient.Quit()
at EnterpriseDT.Net.Ftp.Ssl.SSLFTPClient.Quit()
at EnterpriseDT.Net.Ftp.FTPConnection.Close(Boolean abruptClose)
at EnterpriseDT.Net.Ftp.ExFTPConnection.Close(Boolean abruptClose)
at EnterpriseDT.Net.Ftp.FTPConnection.Close()
at Xxxx.Yyyy.Communication.Client.FTPService.Dispose(Boolean disposing)

The code calling Close:

    
    protected virtual void Dispose(bool disposing)
    {
      if(disposing)
      {
        if(_ftpConnection != null && _ftpConnection.IsConnected)
        {
          _ftpConnection.Close();
        }
      }
    }


Why does this occur, and why an exception for a 125 reply code? and more importantly how should i go about in fixing this. We currently see this behaviour when using the edtFTPnet/PRO 4.1.1.0 version.

3 Answers

0 votes
by (162k points)
Interesting. Can you create a log file (see the User Guide) and email an instance when this happens to support at enterprisedt dot com? Thanks.
0 votes
by (160 points)
Hello,

This problem occurs on a production server and due to some other factors i didnt have the time to start logging on those machines yet, i will eventualy if still needed.
However, in a recent update i changed the error handling and found the real cause of the problem, the exception descriped earlier occured in the Dispose method. But it seems another error occured before the dispose was called (due to a using block), because a new error was being raise in the dispose the original exception was lost.

This is the error that occurs prior to the error from "Close":

System.IO.IOException: An I/O exception occurred. ---> System.IO.IOException: Timed out while reading data
at ct.b(Byte[] A_0, Int32 A_1, Int32 A_2)
at x.c(IAsyncResult A_0)
at ev.a(IAsyncResult A_0)
at ev.a(Byte[] A_0, Int32 A_1, Int32 A_2, SocketFlags A_3)
at d.b(Byte[] A_0, Int32 A_1, Int32 A_2)
--- End of inner exception stack trace ---
at d.b(Byte[] A_0, Int32 A_1, Int32 A_2)
at System.IO.StreamReader.ReadBuffer()
at System.IO.StreamReader.ReadLine()
at EnterpriseDT.Net.Ftp.FTPControlSocket.ReadReply()
at EnterpriseDT.Net.Ftp.FTPControlSocket.SendCommand(String command)
at EnterpriseDT.Net.Ftp.FTPClient.Dir(String dirname, Boolean full)
at EnterpriseDT.Net.Ftp.FTPClient.DirDetails(String dirname)
at EnterpriseDT.Net.Ftp.FTPConnection.GetFileInfos(String directory)
at EnterpriseDT.Net.Ftp.FTPConnection.GetFileInfos()
at Xxxx.Yyyy.Communication.Client.Zzzz.PrepareReceive(String Uuuu)

My timeout is set to 60000, and i dont receive any problems in 95% of the cases, the next attemp ussualy does succeed.
0 votes
by (162k points)
It seems that the first error is the timeout while waiting for the 125 code to be returned. The 125 is then read when Quit() is called in the Close() - which is an unexpected response to Quit().

It may be you need to increase your timeout to say 120s. Or perhaps you are doing many rapid transfers and/or listings and are running out of sockets on the server.

You also may wish to call Close(true) to force an abrupt quit rather than Close() which sends a QUIT message and waits for a response - especially if there is a prior exception leaving the client in an inconsistent state.

Categories

...