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
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
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
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 email@example.com?