16 Stimmen

Die zugrunde liegende Verbindung wurde geschlossen: Die Verbindung wurde unerwartet geschlossen

Diese Ausnahme wird regelmäßig bei einer SOAP-Anfrage ausgelöst, deren Empfang fast drei Minuten dauert und die 2,25 Megabyte groß ist.

Beim Durchsuchen des Internets finde ich alle möglichen Beiträge, die sich alle mit dem Setzen von Headern für die Anfrage zu befassen scheinen. Einige wollen, dass ich den "Expect:"-Header nicht sende, andere wollen, dass ich den "Keep-Alive:"-Header sende, aber unabhängig von den Headern, die ich sende, erhalte ich immer noch diesen lästigen Fehler. Ich glaube nicht, dass das Setzen irgendwelcher Header die Lösung ist, denn Ich kann die gleiche Anfrage mit "curl" wiederholen und eine Antwort kommt schließlich ohne Probleme zurück, was auch immer .

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

Ich habe das Gefühl, dass mir die Möglichkeiten ausgegangen sind. Wenn jemand Hilfe anbieten kann, wäre ich sehr dankbar. Ein paar andere Dinge zu beachten wäre, dass der Server ich bin Requesting Daten aus meinen Händen ist, auch diese Anfragen sind über https und andere Anfragen mit kleineren Antworten funktionieren einwandfrei.

Danke

0 Stimmen

Ich glaube, dass dieses Problem mit lastverteilten Servern zusammenhängt.

11voto

Robert Wagner Punkte 16985

Sie haben den Beitrag als .NET35 gekennzeichnet, verwenden Sie also WCF?

Wenn ja, finden Sie hier ein Beispiel für die App.config, die wir für große Datensätze verwenden:

<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>

2 Stimmen

Nein, ich denke, ich könnte in die Konvertierung zu WCF obwohl aussehen... Ich denke, der ursprüngliche Code wurde von einem Pilotprojekt portiert, das in 2.0 oder vielleicht sogar 1.1 geschrieben wurde.

6voto

Boris Modylevsky Punkte 2867

Ich hoffe, dass es für die Beantwortung dieser Frage nicht zu spät ist.

Versuchen Sie, das folgende Attribut in die Definition Ihrer Vertragsschnittstelle einzufügen:

[ServiceKnownType(typeof(ReturnClass))]

Eine allgemeinere Lösung, die die Rückgabe polymorpher Klassen ermöglicht, finden Sie in diesem Beitrag: http://www.goeleven.com/blog/entryDetail.aspx?entry=45

4voto

sharmaja Punkte 41

Wenn Sie dbml anstelle von edmx verwenden, erhalten Sie diese Meldung (Die zugrunde liegende Verbindung wurde geschlossen: Die Verbindung wurde unerwartet geschlossen.), da dbml keine serialisierbaren Daten zurückgibt, sondern einen Datenvertrag benötigt, gehen Sie zu den Eigenschaften der dbml-Datei und ändern Sie den Serialisierungsmodus auf unidirektional.

0 Stimmen

Das hat mein Problem gelöst, danke Sharmaja! Noch ein Hinweis: Ich musste meine Dienstreferenz auf der Client-Seite aktualisieren, damit das funktioniert. Ich hoffe, das hilft anderen, die in der gleichen Situation sind.

3voto

mkoeller Punkte 4389

Haben Sie schon den Vorschlag von dieser Blogbeitrag ? Das Problem wird höchstwahrscheinlich in der TCP/HTTP-Stack-Implementierung von .NET liegen.

0 Stimmen

Ja, das habe ich versucht, ohne Erfolg. Für mich sieht es so aus, als ob es einen Header "Connection: Keep-Alive"

2 Stimmen

Sie müssen also debuggen, was der .NET HTTP/TCP-Stack tatsächlich tut. Insbesondere, was er im Vergleich zu curl falsch macht. Sie sollten entweder Wireshark (TCP-Netzwerk-Sniffer) oder Fiddler (HTTP-Proxy) zwischen Ihre SOAP-Anfrage und den Server schalten. Auf diese Weise sollten Sie in der Lage sein, den Unterschied zu erkennen.

0 Stimmen

Nun, ich habe bereits den "Webdienst" in einen WCF-Dienst konvertiert, wenn das nicht hilft, werde ich dies versuchen, aber muss untersuchen, wie man die Ergebnisse von Wireshark besser filtern kann... oder vielleicht ist Fiddler netter.

3voto

Ahmad Th Punkte 319

Ich habe das gleiche Problem, und nach eingehenden Recherchen fand ich diesen Artikel:

Merrick Chaffer's Blog

Es war alles im Zusammenhang mit der Einstellung der "dataContractSerializer" sowohl für Client und Server. Hoffe, dass dies hilfreich sein.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X