System.Net.WebException: The request was aborted: the request was cancelled

Question

I have a WCF service that has been giving me this error under load conditions (and I can't seem to recreate the error otherwise). We've been trying to find a way around it for about a week now with no such luck..

The error I see has two parts to it,

System.ServiceModel.CommunicationException: An error: (The request was aborted: the request was cancelled.) occurred while transmitting data over the http channel.

and:

System.Net.WebException: The request was aborted: the request was cancelled.

I've seen many people suggest to disable working with keep alive by overloading a method in the Reference.cs file and setting KeepAlive = false, however, our client side is using a service reference (in addition to web reference) and this option does not exist anymore.

Another option I've seen was to add a custom Binding to the service instead of the BasicHttpBinding we are using now, but that would bother backwards support of the webservice to those who have been using a webReference (since CustomBinding is not SOAP enabled).

Has anyone dealt with this error before? Is there a way to disable keep alive in WCF without affecting the server side? Is there anything other that keep alive that is known to cause this error?

Sumac

You can access Http Context and do what you want. Have a look here: blogs.msdn.com/b/justinjsmith/archive/2007/08/22/… – Arletha

Answer 1

I don't think that HTTP keep alive is responsible for this. WCF should be able to handle this by itself so the HTTP persistant connection is shared among requests and if it expires (it expires after 100s of inactivity) WCF creates new one without firing any exception. If your connection is aborted during request transmission then I expect there will be some other problem.

You can use this custom binding as equivalent to BasicHttpBinding without HTTP keep alive:

<bindings>
  <customBinding>
    <binding name="NoKeepAlive">
      <textMessageEncoding messageVersion="Soap11" />
      <httpTransport keepAliveEnabled="false" />
    </binding>
  </customBinding>
</bindings> 

Plumcot

Yes, it is responsible and I have seen it before. – Arletha

Wow, I just experienced this myself. What a surprise. Thanks, @Arletha – Dumps

@Arletha Just out of curiosity, are you also calling a Tomcat-based Java web service? – Dumps

Answer 2

I had this problem when trying to upload large files. I had to add this to the web.config of the web services

<system.web>
  <httpRuntime maxRequestLength="10240" />

Tripper

Answer 3

I had this exact same problem. In my case I was executing requests ASynchronously. I was sending a few hundred requests to the 'server' from my client. I am/was using basicHttpBinding. And in my app.config setting the openTimeout property was set to 60 seconds or one minute. Once I set that to a bigger number like 10 minutes, the problem has gone away.

So for instance I changed all these values in my app.config file:

<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IScriptRunHost" closeTimeout="00:10:00"
                    openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"

to 10 minutes.

Vocative

Answer 4

This error can also be caused by mixing using clauses with asynchronous calls to WCF services.

For example:

using (ServiceClient proxy = new ServiceClient(proxyName)) {
  proxy.Open();
  return proxy.FunctionCallAsync(parameters); //Return type being Task<ResultSet>
}

This will trigger a race condition between how fast can it dispose of proxy versus how fast the asynchronous Task<ResultSet> can be completed. Longer the task takes the more likely it will be to end up in a Faulted state and the Result containing a System.ServiceModel.CommunicationException.

This can be fixed by removing the using clause:

ServiceClient proxy = new ServiceClient(proxyName))
proxy.Open();
return proxy.FunctionCallAsync(parameters); //Return type being Task<ResultSet>

Note that proxy should be persisted too so that once the asynchronous call is completed that a proxy.Close() can be done.

Pyridoxine

This was helpful for my issue as well, which was a bit different: if your OperationContract returns Task<...> (as in Task<Foo> LoadFoo();), the issue is similar, disposing of the proxy beats resolving the Task to get reponse data. Bad API, yes, but that's what I have. – Frith

I would advise to fix the race condition by simply awaiting the proxy.FunctionCallAsync. Not awaiting async code inside a using can produce all kinds of undefined behavior and should be avoided – Prager

Answer 5

add this in app.config

 <system.net>
 <connectionManagement>
      <add address="*" maxconnection="5"/>
                <add address="https://api.limitedconnections.com*" maxconnection="2"/>                
                <add address="https://api.moreconnections.com*" maxconnection = "10"/>
        </connectionManagement>
</system.net>

Refer the below link

https://cdijkgraaf.wordpress.com/2019/12/02/configuring-maxconnection-in-biztalk/

Maloriemalory