Core Service error when using Stream Bindings

Question

I have quite a specific problem which I'm hoping I can explain thoroughly enough for someone to be able to help me with. Basically I've been working on a script that uses the the Core Service (2011) to create a copy of components to a different publication. So far so good :)

When running my script on an internal development environment everything works fine, but as soon as I try to run on the clients server I see errors like the one below:

An error occurred while receiving the HTTP response to http://xxx/webservices/CoreService2011.svc/streamUpload_basicHttp. 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.

I have managed to narrow the problem down to Binary Components, so, to test this I have created a test method with a Multimedia Component that contains Binary Content. At the end I simply try writing out the filepath, filename etc.

public static class TestClass
{
    private static readonly string Hostname = ConfigurationManager.AppSettings["hostname"];
    private static readonly string ImpersonateUser = ConfigurationManager.AppSettings["impersonate_user"];
    private static readonly string ImpersonatePassword = ConfigurationManager.AppSettings["impersonate_password"];

    public static void StreamRequest()
    {
        var client = CoreServiceHandler.GetNewClient(Hostname, ImpersonateUser, ImpersonatePassword);
        var compData = (ComponentData)client.Read("tcm:362-59547", null);

        var origFilename = compData.BinaryContent.Filename;
        var extension = origFilename.Substring(origFilename.LastIndexOf('.') + 1);
        string tempPath;

        // Upload binary content to cms 
        using (var suClient = new StreamUploadClient("streamUpload_basicHttp"))
        using (var sdClient = new StreamDownloadClient("streamDownload_basicHttp"))
        using (var tempStream = sdClient.DownloadBinaryContent(compData.Id))
        {
            // Uses the content stream from original component 
            tempPath = suClient.UploadBinaryContent(origFilename, tempStream);
        }

        // Find multimedia type
        var list = client.GetSystemWideList(new MultimediaTypesFilterData());
        var multimediaType = list.OfType<MultimediaTypeData>().Single(mt => mt.FileExtensions.Contains(extension));

        Console.WriteLine("tempPath {0}:", tempPath);
        Console.WriteLine("origFilename {0}:", origFilename);
        Console.WriteLine("multimediaType.Id {0}:", multimediaType.Id);
    }
}

I get the error on this line:

tempPath = suClient.UploadBinaryContent(origFilename, tempStream);

A quick Google suggests it could be due to not being able to pass around IEnumerable<T> along with a few people recommending configuration changes to my app config which also haven't worked.

This is where I turn to you guys! I've hit a brick wall so any help whatsoever would be greatly appreciated.

UPDATE

I've been debugging this further and I'm 99% sure the problem is with the size of the binary item. The MM component causing the issue contains a PDF with a size of 7.9 MB and that's when I see the error. I confirmed my suspicion by creating a new MM component with a 1 MB PDF and I got no error.

What I don't understand is why the size of the binary item would matter? I would expect my script to just take longer to execute not break totally? Either way, I'm thinking I need to adjust my app settings to handle i.e. the maxReceivedMessageSize attribute.

I'll try this and update accordingly.

FURTHER UPDATE

Increasing the maxReceivedMessageSize and maxBufferSize attributes doesn't resolve the issue. This is my config file:

  <system.serviceModel>
  <bindings>
      <basicHttpBinding>
          <binding name="streamDownload_basicHttp" maxReceivedMessageSize="64000000" maxBufferSize="64000000"> 
              <security mode="TransportCredentialOnly">
                  <transport clientCredentialType="Windows" />
              </security>
          </binding>
          <binding name="streamUpload_basicHttp" messageEncoding="Mtom" maxReceivedMessageSize="64000000" maxBufferSize="64000000"> 
          </binding>
      </basicHttpBinding>
  </bindings>
  <client>
      <endpoint address="http://abc/webservices/CoreService2011.svc/streamDownload_basicHttp"
          binding="basicHttpBinding" bindingConfiguration="streamDownload_basicHttp"
          contract="CoreService.IStreamDownload" name="streamDownload_basicHttp" />
      <endpoint address="http://abc/webservices/CoreService2011.svc/streamUpload_basicHttp"
          binding="basicHttpBinding" bindingConfiguration="streamUpload_basicHttp"
          contract="CoreService.IStreamUpload" name="streamUpload_basicHttp" />
  </client>

Answer 1

IIS defaults the maximumRequestLength to 4Mb so your request will be rejected if it exceeds this.

You can increase this by adding

<httpRuntime maxRequestLength="1048576" executionTimeout="3600" />

to your web.config for the service.

Answer 2

At a very high level, it looks like either a permission related issue or a binding mismatch issue.

I would suggest following measures:

1. Ensure The Application pool identity with which the Service is running on the Server have appropriate right to upload files on the Disk - Note that WCF by default will not impersonate the caller, thus the identity used to run your service will need to have sufficient permissions on all resources that your service needs to access. This includes the temp folder, which is used to provide the WSDL file for HTTP GET.

2. You have binding mismatch and a mismatch in the client/server bindings, WSHttpBinding uses SOAP 1.2, BasicHttpBinding uses SOAP 1.1. Can you verify that the bindings used by the client/server are the same?

3. Verify by using smallest possible or 1 KB size file to ensure there is no issue with the Size

On the other hand you can use following to get an actual/more elaborated error, if you try following ways to debug the Service:

• Inspect HTTP traffic using Fiddler and see if there is anything wrong with the MTOM encoded request
• Trace your service using the Service Trace Viewer Tool and see if any other meaningful observation can be figured out.