Null reply during syncing

Question

I received this error twice now.
The syncing fails due to an unexpected null reply received.
Here's a piece of the log file:

226 Transfer complete.
Found 264 listing lines
Parse() called using culture: Invariant Language (Invariant Country)
---> CDUP
250 CWD command successful.
---> PWD
257 "/DSAutomation/DRE/SDS/BE" is current directory.
---> CDUP
250 CWD command successful.
---> PWD
257 "/DSAutomation/DRE/SDS" is current directory.
---> CWD BG
421 Terminating connection.
---> CWD /
Exception in SendCommand
Command error
Stopping FTP task processor.
FTP task processor stopped.
---> QUIT
Exception in SendCommand
Command error
Failed to sync E:\DataSheets to /DSAutomation/ because Unexpected null reply rec
eived. This was attempt 0
Stopping FTP task processor.
FTP task processor stopped.

The "Faild to sync E:\DataSheets to /DSAutomation/ because" and "This was attempt 0" parts are logging from my own program.
I currently just do a complete retry around the sync. As you understand, this is an ugly sollution.

Any idea what the null reply could be? Am I doing something wrong, or is there something wrong with the library.
It happens only occasionally, with no warning. Last time it was already running for a complete week before it happened.
Now it happend after a minute or so. Both were to seperate servers (first was MediaHost and second was NetworkSollutions).[/code]

Answer 1

Hi Boris

We've recently changed the handling of 421 replies so that an exception is thrown to say that the connection has closed. I think the version you have doesn't throw an exception, but simply continues as though everything is OK.

The latest version, 5.0.2, includes this fix, but it doesn't include the directory-checking patch we did for you a couple of weeks ago, so I wouldn't recommend installing it yet. The reason why 5.0.2 doesn't include this patch is that you hadn't yet confirmed if it solved the problem you were having with multiple clients synchronizing simultaneously. Did that work out OK?

Anyway, the changed handling of 421 won't actually fix your problem directly, although it will allow you to react more appropriately when you detect the error.

The FTP specification's definition of a 421 response is:

421 Service not available, closing control connection.
    This may be a reply to any command if the service knows it
    must shut down.

Unfortunately this doesn't actually tell us what went wrong. The quickest way to work that out would be to look in the server logs. Is that possible for you?

- Hans (EnterpriseDT)

Answer 2

Ah, I see.

As the answer to your first question: Yes, it is working out nice.
There are no more collisions there :)
Sorry for not letting you know. Tons of other stuff and their deadlines have taken up my full attention this week.

The hosting is a shared one, not in our maintenance. I fear I won't be able to get a hold of that.
Well, I guess the retry isn't all THAT bad; it's just ... not how it should be ;)
The weird thing is though, it happens at two totally unrelated servers. One's a Linux one, the other a win system.
One's Serv-u, other's something else I didn't check yet.
One time it was after running for a week, the other was after half a minute or so.

The error only happens really seldom, so the hard part is recreating it...
There just doesn't seem to be any pattern in it.
I do realize I'm not being very helpfull here :S

Answer 3

Hi Boris

OK, I'm glad that anti-collision patch worked. We'll roll into our mainline and create a new distribution for you. We'll send you an e-mail when it's ready for you to collect. As I mentioned, the new behaviour for the 421 reply is to throw an exception. This will at least allow you to detect the error and take remedial action immediately.

A couple of questions: Does it happen in the same directory every time? Is the same server being updated from multiple clients at the same time - in other words, could this be the result of a different kind of collision somehow?

- Hans (EnterpriseDT)

Answer 4

The first time this could have been the case as I use multiple connections pointing to the same host.
The second time however, this was only one connection that transferred files from a local directory that wasn't accesed by anything else to a destination directory that wasn't accessed either.