Intermittent issue with receiving deliveries

[donss]

Hi,

Occasionally, we had reports of users who are downloading a delivery sent to them that when they downloaded using the DigiDelivery client, all they ended up was one or more folders and not the file(s) in the delivery. Having spoke with them, it seems like the folder have the names of the files that were in the delivery... Has anyone else had this problem?

Don

[Frank Kruse]

I haven´t seen this myself but there´s too little info in your posting to help you.

-Which OS?
-Was there an error-message from the client or did the download finish successfully (including the notification e-mail)?
-Which client version?
-What does the client history say about those deliveries?
-Ask them to create a folder named "Logs" next to the client program and resend the same files. If it happens again, check the log files in that folder.

Frank.

[donss]

I don't have information about which OS or the version our users are using. I would presume they are likely to be using the latest version of the client.
I did get the delivery email back from the user and tried to download the package myself and had the same thing happen. The client does not error but finishes receiving the files as soon as you confirm the directory where you want to receive the file(s). The receipt confirmation email is sent and the package is marked as received on the server. I am using XP SP3 with client version 2.2.1b394. I cannot reproduce the fault anymore as we expire the delivery 2 days after a successful receipt and it has been more than a couple of days. We normally re-upload the delivery and send. We've not noticed same issue with these re-sends so far.

On the server, the delivery is about 8GB big and not 0 (a couple of empty folders - even if you could upload them). 8GB should take a good 10 minute even if you have a pretty good connection and not a fraction of a second (wish we had bandwith that big... but alas...)

As I indicated that this does not happen frequently. I think I am going to wait till the next reported occurence. ITMW, I will create the Log folder as you suggested and see what gets logged.

I hope the info here helps but it sounds like this is not a well known issue. I will post the Log the next time the issue happens and our customer(s) report it - sometimes the business just resends the deliveries.

Thanks.

[Frank Kruse]

Very strange indeed. Not once in many years of non-stop DD operation have I encountered what you describe.
Sorry I don´t have any tips from what you described. Maybe check out the log-files next time it happens.

Since the data on the servers shows up as 8GB my guess is that it´s an issue wich the client trying to write to the local drive. But I´m just guessing here.

Can XP write files larger than 4GB onto a drive? (sorry, I´m a mac guy)

If all else fails, contact Aspera.

Frank.

[donss]

Yes one can have files bigger than 8GB. I have downloaded bigger files before and since.

Further to this post, I've found the Logs folder on the client directory and found the log on the time I reproduced the problem. This is what is in the log: -

05/26/2010, 09:49:41.000, Debug, DD_ApplicationWin.cpp DD_ApplicationPriv::InitInstance 131
Sending CopyData msg and exiting.
05/26/2010, 09:49:41.000, Throw, \code\azul_Digidelivery\Apps2\DigiDeliveryClient\C ommon\DelivApp\Application\DD_Prefs.cpp 101
DIGID_UNKNOWN_ERROR: s_prefsFile.size()

I hope this can help you to tell us what the problem is.

Don

[donss]

I have another log file which was created a minute later that has even more information.

I could paste the lot... but decided paste bits that have errors in them

...
05/26/2010, 09:42:43.828, Debug, DgD_CRC32.cpp DgD_CachedCRC32::init 135
Checksum value = 0 - file doesn't exist: C:\Documents and Settings\dshin.CORP\Application Data\DigiDelivery\1274863354944138_0.delivery\chec ksum\6201b28f974798af8358-rnsf_0
05/26/2010, 09:42:43.828, Warning, DgD_CRC32Util.cpp DgD_CRC32Util::verifyChecksums 102
6201b28f974798af8358-rnsf_0 Checksum error: expected 0, but got 1607077375
05/26/2010, 09:42:43.828, Warning, DgD_RcvDelivTxn.cpp DgD_RcvDelivTxn::QueryServer 318
Deleting C:\zbin\DigiDelivery\OLD DOGS\6201b28f974798af8358-rnsf due to checksum error
05/26/2010, 09:42:43.828, Error, DgD_FileSystemUtilities.cpp DeleteFile_ 1067
Delete failed. GetLastError() = 2
05/26/2010, 09:42:43.843, Debug, DgD_HttpTxn.cpp DgD_HttpTxn::LogMessage 302
...
...
05/26/2010, 09:47:44.943, Throw, DgD_SocketWin.cpp DgD_Socket::Read 187
DIGID_RECV_FAILED: errno = 10054
05/26/2010, 09:47:44.959, Catch, DgD_RemoteMsgBroker.cpp DgD_RemoteMsgBroker::RunMsgLoopFunc 439
DIGID_RECV_FAILED: errno = 10054
...
...
05/26/2010, 09:49:47.258, Debug, DgD_CRC32.cpp DgD_CachedCRC32::init 135
Checksum value = 0 - file doesn't exist: C:\Documents and Settings\dshin.CORP\Application Data\DigiDelivery\1274863781671081_2.delivery\chec ksum\6201b28f974798af8358-rnsf_0
05/26/2010, 09:49:47.258, Warning, DgD_CRC32Util.cpp DgD_CRC32Util::verifyChecksums 102
6201b28f974798af8358-rnsf_0 Checksum error: expected 0, but got 1607077375
05/26/2010, 09:49:47.258, Warning, DgD_RcvDelivTxn.cpp DgD_RcvDelivTxn::QueryServer 318
Deleting C:\zbin\DigiDelivery\OLD DOGS 1\6201b28f974798af8358-rnsf due to checksum error
05/26/2010, 09:49:47.258, Error, DgD_FileSystemUtilities.cpp DeleteFile_ 1067
Delete failed. GetLastError() = 2
05/26/2010, 09:49:47.258, Debug, DgD_HttpTxn.cpp DgD_HttpTxn::LogMessage 302
...
...
05/26/2010, 09:49:22.915, Error, DgD_FileSystemUtilities.cpp DeleteFolder 206
RemoveDirectoryW failed 145
05/26/2010, 09:49:22.915, Error, DgD_FileSystemUtilities.cpp DeleteFolder 206
RemoveDirectoryW failed 145
05/26/2010, 09:49:22.915, Error, DgD_FileSystemUtilities.cpp DeleteFile_ 1067
Delete failed. GetLastError() = 32
05/26/2010, 09:49:22.915, Error, DgD_FileSystemUtilities.cpp DeleteFile_ 1067
Delete failed. GetLastError() = 32
05/26/2010, 09:49:22.993, Throw, DgD_SocketSsl.cpp DgD_SocketSsl::Read 129
DIGID_RECV_FAILED: errno = 10053
05/26/2010, 09:49:23.071, Throw, DgD_SocketWin.cpp DgD_Socket::Read 187
DIGID_RECV_FAILED: errno = 10054
...

If you need the whole log, let me know.

Cheers.

Don

[Frank Kruse]

I see lots of checksum-errors. This means that the data´s checksum doesn´t match what was sent so the client deletes the entire file because it "thinks" the data is corrupted anyway.

I recommend you send this to chris markle at aspera because it´s definitly not normal. Especially when it happens rather often. I haven´t seen this once in years. Maybe there´s something wrong with your system that leads to the error. Do you have the latest server-firmware installed?

Sorry at this point I´m out of wisdom. You need to contact Aspera.

Frank.

[donss]

We have v2.2.1.
We've been using DigiDelivery for a good 2 years and only recently we started to get the problem but only now and then. Vast majority is fine and re-sends, so far are fine. I have rebooted the delivery server. I hope it clears the "glitch" and, if not, at least delay the next occurence.

Thank you for all your help. I will find out what the situation is regarding contacting Aspera.

Cheers.

Don

[Frank Kruse]

If you ever receive an answer from them let me know what the reason for the hickup was.

Thanks,

Frank.