The underlying connection was closed: The connection was closed unexpectedly
Asked Answered
E

10

16

This exception is consistently thrown on a SOAP Request which takes almost three minutes to receive and is 2.25 megs in size.

When scouring the web I find all sorts of posts which all seem to be about setting headers on the Request, some want me to not send the "Expect:" header, some want me to send the "Keep-Alive:" header, but irregardless of the headers I send I still get this pesky error. I don't believe that setting any headers is my answer, because I can recreate the exact same request using "curl" and a response does eventually come back with no problems what-so-ever.

My <httpRuntime maxRequestLength="409600" executionTimeout="900"/>.

I feel as if I'm running out of options. If anyone can provide any assistance I would be most grateful. A few other things to note would be that the server I'm Requesting data from is out of my hands, also these requests are over https and other requests with smaller responses work flawlessly.

Thanks

Ethelind answered 12/11, 2008 at 20:56 Comment(1)
I believe this problem is related to load balanced servers.Ethelind
G
11

You tagged the post as .NET35, so are you using WCF?

If so, here is an example of the App.config we use for large data sets:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
          <readerQuotas maxDepth="32" maxStringContentLength="8388608" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
        </binding>
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:1602/EndPoint.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding" contract="IEndPointContract" name="EndPoint" behaviorConfiguration="EndpointBehaviour" />     
    </client>
    <behaviors>
      <endpointBehaviors>
        <behavior name="EndpointBehaviour">
          <dataContractSerializer maxItemsInObjectGraph="2147483647" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
Gertrudegertrudis answered 12/11, 2008 at 22:5 Comment(1)
No, I guess I might look into converting to WCF though... I think the original code was a ported from a pilot written in 2.0 or maybe even 1.1.Ethelind
F
6

I hope it's not too late for answering this question.

Try adding the following attribute on the definition of your contract interface:

[ServiceKnownType(typeof(ReturnClass))]

For more generic solution that allows returning polymorphic classes please refer to this post: http://www.goeleven.com/blog/entryDetail.aspx?entry=45

Ferous answered 16/6, 2009 at 21:4 Comment(0)
M
4

If you are using dbml instead of edmx you will get this( The underlying connection was closed: The connection was closed unexpectedly.) as dbml will not return serialisable data it needs datacontract so go to properties of dbml file and change the Serialization mode to unidirectional.

Motorize answered 19/11, 2011 at 9:15 Comment(1)
This solved my problem, thanks sharmaja! One more note, though: I had to update my service reference on the client side in order to get this to work. Hope this helps others in the same situation.Covet
M
3

Have you tried the sugestion of this Blog Post? The problem will most probably lie in the TCP/HTTP stack implementation of .NET .

Menell answered 12/11, 2008 at 21:3 Comment(5)
Yeah tried that, no luck, to me it just appears to set a header "Connection: Keep-Alive"Ethelind
So you need to debug what the .NET HTTP/TCP stack is actually doing. Especially what it's doing wrong in comparison to curl. You should place either Wireshark (TCP network sniffer) or Fiddler (HTTP proxy) between your SOAP request and the server. This way you should be able to spot the difference.Menell
Well, I've already convert the "web service" to a WCF service, if that doesn't help, I'll try this, but will need to investigate how to better filter the results from wireshark... or maybe Fiddler is nicer.Ethelind
Fiddler is generally more appropriate for HTTP debugging. However, sometimes TCP level analysis may be needed. Have you noticed the "follow TCP stream" feature in Wireshark? That saves quite some time.Menell
no I hadn't noticed that, I will definitely look in to that, thanks!Ethelind
A
3

I've got the same issue, and after deep investigations I found this article:

Merrick Chaffer's Blog

It was all related to setting the "dataContractSerializer" for both client and server. Hope this to be helpful.

Adrenal answered 2/8, 2010 at 9:16 Comment(0)
S
3

i got this error because my datatransfereobjects refered to each other in an recursive manner.

For example:

Customer-> (has) -> Rating Rating-> (belong to) -> Customer

so you have to remove cycles.

[DataContract]
public class Rating
{
    private Customer _customer;
    //[DataMember] // <-  EITHER HERE 
    public Customer Customer
    {
        get { return _customer; }
        set { _customer = value; }
    }
}


[DataContract]
public class Customer
{
    private long _customerID;
    [DataMember]
    public long CustomerID
    {
        get { return _customerID; }
        set { _customerID = value; }
    }

    [DataMember] // <- OR HERE
    public Rating Rating
    {
        get { return _rating; }
        set { _rating = value; }
    }
}
Spec answered 14/1, 2012 at 14:38 Comment(0)
E
3

Tried several ways to get rid of this error message until I found this solution: http://kiranpatils.wordpress.com/2008/09/22/the-underlying-connection-was-closed-the-connection-was-closed-unexpectedly-while-returning-data-table-from-wcf-service/

You may change your List<> to DataSet. I suspect DataSet can handle much amount of data than the List<>.

Hope it helps.

Euratom answered 26/6, 2013 at 13:17 Comment(0)
K
2

I have added another field, but didn't have a set on the property. That was my solution for the same error.

[DataMember]
public bool HasValue
{
    get { return true; }
    set { }//adding this line made the solution.
}
Kinzer answered 20/9, 2011 at 8:21 Comment(0)
C
1

This is a generic error raised if there is an internal error.

Try adding tracing here: http://msdn.microsoft.com/en-us/library/ms732023(v=vs.110).aspx

You will see the full log then.

Cockney answered 15/7, 2014 at 11:45 Comment(0)
N
0

For WCF with EF, just add the following code in the context class.

base.Configuration.ProxyCreationEnabled = false;

Neuro answered 27/11, 2013 at 18:53 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.