2008-11-12 20 views
16

Esta excepción se lanza consistentemente en una solicitud SOAP que tarda casi tres minutos en recibir y tiene un tamaño de 2,25 megas.La conexión subyacente se cerró: La conexión se cerró inesperadamente

Al buscar en la web, encuentro todo tipo de publicaciones que parecen ser sobre cómo configurar encabezados en la Solicitud, algunos quieren que no envíe el encabezado "Esperar:", algunos quieren que envíe el "Keep-Alive: "encabezado, pero independientemente de los encabezados que envío, sigo recibiendo este molesto error. No creo que la configuración de ningún encabezado sea mi respuesta, porque puedo recrear exactamente la misma solicitud utilizando "curl" y finalmente una respuesta vuelve sin problemas.

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

Siento que me estoy quedando sin opciones. Si alguien puede proporcionar cualquier asistencia, le estaría muy agradecido. Algunas otras cosas a tener en cuenta serían que el servidor del que estoy solicitando datos está fuera de mis manos, también estas solicitudes están sobre https y otras solicitudes con respuestas más pequeñas funcionan sin problemas.

Gracias

+0

Creo que este problema está relacionado con los servidores de carga equilibrada. – Dave

Respuesta

3

¿Usted ha intentado la sugerencia de this Blog Post? El problema probablemente sea la implementación de la pila TCP/HTTP de .NET.

+0

Sí, lo intenté, no tuve suerte, para mí solo parece establecer un encabezado "Conexión: Keep-Alive" – Dave

+2

Por lo tanto, debes depurar qué está haciendo realmente la pila .NET HTTP/TCP. Especialmente lo que está haciendo mal en comparación con curl. Debe colocar Wireshark (sniffer de red TCP) o Fiddler (proxy HTTP) entre su solicitud SOAP y el servidor. De esta manera, usted debería ser capaz de detectar la diferencia. – mkoeller

+0

Bueno, ya he convertido el "servicio web" a un servicio WCF, si eso no ayuda, intentaré esto, pero tendré que investigar cómo filtrar mejor los resultados de wireshark ... o tal vez Fiddler es más agradable. – Dave

11

Has etiquetado la publicación como .NET35, ¿estás usando WCF?

Si es así, aquí es un ejemplo de la App.config utilizamos para grandes conjuntos de datos:

<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

No, creo que podría considerar la conversión a WCF ... Creo que el código original fue portado por un piloto escrito en 2.0 o tal vez incluso 1.1. – Dave

+0

Las cosas parecen felices, gracias por la sugerencia – Dave

6

espero que no sea demasiado tarde para responder a esta pregunta.

Trate de añadir el siguiente atributo en la definición de la interfaz de contrato:

[ServiceKnownType(typeof(ReturnClass))]

Para la solución más genérica que permite devolver clases polimórficas por favor refiérase a este post: http://www.goeleven.com/blog/entryDetail.aspx?entry=45

3

tengo la misma cuestión y después de profundas investigaciones he encontrado este artículo:

Merrick Chaffer's Blog

Se estaba relacionado con la configuración del "dataContractSerializer" para el cliente y el servidor. Espero que esto sea útil.

2

He agregado otro campo, pero no tengo un conjunto en la propiedad. Esa fue mi solución por el mismo error.

[DataMember] 
public bool HasValue 
{ 
    get { return true; } 
    set { }//adding this line made the solution. 
} 
4

Si está utilizando dbml en lugar de edmx obtendrá esto (la conexión subyacente se cerró:. La conexión se cierra de forma inesperada) como dbml no devolverá los datos serialisable que necesita DataContract así que ve a las propiedades de dbml archivo y cambie el modo de serialización a unidireccional.

+0

Esto resolvió mi problema, gracias sharmaja! Sin embargo, una nota más: tuve que actualizar mi referencia de servicio en el lado del cliente para que esto funcione. Espero que esto ayude a otros en la misma situación. –

3

Tengo este error porque mis datatransfereobjects se refieren entre sí de forma recursiva.

Por ejemplo:

Cliente-> (HAS) -> Clasificación Clasificación de > (pertenece a) -> Cliente

Así que hay que eliminar ciclos.

[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; } 
    } 
} 
+0

Gracias, su solución me ayudó. – user1429899

0

Para WCF con EF, simplemente agregue el siguiente código en la clase de contexto.

base.Configuration.ProxyCreationEnabled = false;

Cuestiones relacionadas