Communication Exception: Error when transfering 80 MB DWG file

Nov 17, 2008 at 2:00 PM

Transferring a 80 MB Autocad file (*.dwg) from our network using outlook add in resulted in the following error


System.ServiceModel.CommunicationException: An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace:
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(WebException webException, HttpWebRequest request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Send(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at ITransferService.Upload(RemoteFileDescriptor request)
   at TransferServiceClient.ITransferService.Upload(RemoteFileDescriptor request)
   at TransferServiceClient.Upload(String ContentType, String Email, Guid FileGuid, String FileName, String HashCode, Int64 Length, String SecurityCode, Stream Stream)
   at Memba.Transfer.PlugIns.WCFPlugIn.Upload(Object state)

Nov 17, 2008 at 2:03 PM
Ahh i just noticed that Transfer controller states the file size was 142 MB which means it exceeded the limit but the applicaiton did not catch the error situation well
Nov 17, 2008 at 2:07 PM
Edited Dec 3, 2008 at 2:12 PM
Thank you for reporting this issue. We will look into it and make sure the application reports an comprehensible message in the future.
In the meantime, please note that you can configure Velodoc XP Edition to support uploads larger than 100 MB as explained in the documentation.

Nov 17, 2008 at 2:14 PM
Thanks for the quick reply.  Along with this problem is a workflow / logic issue.

If the upload fails, the email still goes out to the recipient.  When the recipient clicks on the URL in their message they are greeted by a file not found page. 

It would be best if the message was not sent until the transfer controller confirmed that the file upload was successful.
Nov 17, 2008 at 6:48 PM
Thank you for your feedback. This workflow/logic issue has been the subject of long discussions both internally and with some customers involved in the design.

Potentially uploads may last for dozens of minutes if not hours, and a key requirement in the design was that the duration of a transfer should be transparent to Outlook. In other words, users should be able to click the Send button and immediately continue other tasks in Outlook including the possibility to close Outllook.

Considering that Outlook may be closed by the end of a transfer, there is no easy way to notify Outlook that a transfer has completed. For version 1.0 and considering that errors should not be the rule, we have decided to send the email before the transfer has completed. In the future we may improve that by keeping the email in the Outbox and running a polling mechanism to periodically check whether the associated transfer has completed, knowing that if Outllook is closed the polling mechanism will only confirm that the associated transfer has completed once Outllook is restarted. But this is only version 1.0 and we need to leave some improvements for version 2.0, don't we?
Nov 17, 2008 at 8:22 PM

i understand the desire for a release 2.0 of this workflow / logic.  But i would encourage you to think about it sooner as it not user friendly - the user sends the message, email goes out, the file(s) are uploaded and fail.  But the user is left with a message and they click on it to access the files.  But are greeted with a Files not found page - not a great impression for a user.

Would it be possible to at least send out a message to the user stating that the upload failed and the sender needs to try again.  At least this way the user is not left wondering what just happened.

Or the other work flow is user sends message, email goes out, files are still being uploaded and user tries to access the files via the dowlonad URL but they are not complete.
Dec 2, 2008 at 4:09 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.