+1 vote
by (320 points)
edited

I am getting the error when I try to hit FTP Server in both Active/Passive Modes.

"Cannot send command to the server because the response for previous one was not received."

I am nullifying the connection object everytime and re-connecting in the next attempt. Still I get the error. What should I do ?

Applies to: Rebex FTP/SSL

3 Answers

0 votes
by (58.9k points)
edited

Please create a log of communication and either post it here or send it to support@rebex.net. It should enable us to see what is going on. Thanks!

by (320 points)
edited

I have emailed that

by (58.9k points)
edited

The log you sent by email is not created by the Ftp.LogWriter property. It seems to be an internal log of your application and it only contains the exception stack trace but no FTP communication is logged there. So please you need to use the LogWriter property of the Rebex.Net.Ftp class to generate Rebexlog:

Ftp client = new Ftp();
// change the log path if needed
client.LogWriter = new Rebex.FileLogWriter(@"c:\temp\log.txt", Rebex.LogLevel.Debug);

and send the log back to us.

The detailed howto create Rebex log file is described at http://www.rebex.net/kb/logging/default.aspx

0 votes
by (58.9k points)
edited

Hello,

this has already been discussed at our forum. Please check the answer.

by (320 points)
edited

I dont want to check "FTPState.Ready" everytime I do this. This issue is happening with just one of our 5000 customers. If I am going to check "FTPState.Ready" for each one of the 5000 customers, it is going to affect the performance of our system.

0 votes
by (58.9k points)
edited

The answer only suggests to check the Ftp.State property when an Exception is actually thrown by Rebex and processed in the catch block by you. We did not suggest to check the property everytime you do some operation with the Ftp class. Moreover I am sure that checking a property which only returns a content of the field will definitely cause no performance overhead as retrieving the property is not a network operation. For completeness - here is the whole answer I linked above:

This exception ["Cannot send command to the server because the response for previous one was not received."] should only be thrown after a previous FtpException (representing the actual cause of the problem) was silently ignored.

The cause of the first exception is usually a timeout while waiting for the response of a command that the client sent to the FTP server. When a timeout or similar exception occurs, the Ftp object is most likely left in an unusable state because it has not received the response it was waiting for, and any attempt to send another command would most likely result in a similar problem. Therefore, if the application tries to issue another FTP command using an Ftp object in this state, we throw the exception you are seeing.

To handle this, detect the "bad" state of the Ftp object after catching the first FtpException that caused it - simply check whether Ftp object's State property is FtpState.Ready. If it's not, re-connect and try again.

It might also help to create a communication log using Ftp object's LogWriter property (as described at http://www.rebex.net/kb/logging/) - looking into the log, it should be easily possible to tell what is going on and what caused the bad state in the first place.

So please try to make sure that you do not miss any exceptions, check the State of the Ftp object after processing the exception as suggested above and if it does not help, please send us a complete Rebex log created by the LogWriter property.

Moreover, I was unable to locate your Support Contract - could you please send us your support contract details to support@rebex.net?

by (320 points)
edited

I will send you the contract details and rebex logging by email. Coming back to the exception, as I mentioned before, I am creating a new FTP object every time. I am also nullifying it after it is done. So, still, do I need to check for the "bad" state ?

by (58.9k points)
edited

Well, without seeing the code, log file, or knowing what you mean by "every time" it is very hard to tell what is actually going on in your program. So checking for the bad state of the Ftp object when handling exceptions is really recommended.

If you send us the log file of the communication which ended with the FtpException "Cannot send command to the server because the response for previous one was not received.", it should enable us to see what is going on and advise. Looking forward to see the log. Btw. the support contract details did not arrive yet into our mailbox.

...