receivetimeout - WCF timeout excepción investigación detallada
wcf timeout c# (12)
Tenemos una aplicación que tiene un servicio WCF (* .svc) ejecutándose en IIS7 y varios clientes que consultan el servicio. El servidor ejecuta Win 2008 Server. Los clientes ejecutan Windows 2008 Server o Windows 2003 server. Recibo la siguiente excepción, que he visto que de hecho puede estar relacionada con una gran cantidad de posibles problemas de WCF.
System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to ''http://www.domain.com/WebServices/myservice.svc/gzip'' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.
Aumenté el tiempo de espera a 30 minutos y el error aún ocurrió. Esto me dice que hay algo más en juego, porque la cantidad de datos nunca podría tomar 30 minutos para cargar o descargar.
El error viene y se va. Por el momento, es más frecuente. No parece importar si tengo 3 clientes corriendo simultáneamente o 100, todavía ocurre de vez en cuando. La mayoría de las veces, no hay tiempos de espera, pero todavía recibo algunos por hora. El error proviene de cualquiera de los métodos invocados. Uno de estos métodos no tiene parámetros y devuelve un poco de datos. Otro toma muchos datos como parámetro pero se ejecuta de forma asíncrona. Los errores siempre se originan en el cliente y nunca hacen referencia a ningún código en el servidor en el seguimiento de la pila. Siempre termina con:
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
En el servidor: he intentado (y actualmente tengo) las siguientes configuraciones de enlace:
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"
No parece tener un impacto.
Intenté (y actualmente tengo) las siguientes configuraciones de aceleración:
<serviceThrottling maxConcurrentCalls="1500" maxConcurrentInstances="1500" maxConcurrentSessions="1500"/>
No parece tener un impacto.
Actualmente tengo la siguiente configuración para el servicio WCF.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]
Funcioné con ConcurrencyMode.Multiple por un tiempo, y el error todavía ocurrió.
Intenté reiniciar IIS, reiniciar el SQL Server subyacente y reiniciar la máquina. Todos estos no parecen tener un impacto.
Intenté desactivar el firewall de Windows. No parece tener un impacto.
En el cliente, tengo estas configuraciones:
maxReceivedMessageSize="2147483647"
<system.net>
<connectionManagement>
<add address="*" maxconnection="16"/>
</connectionManagement>
</system.net>
Mi cliente cierra sus conexiones:
var client = new MyClient();
try
{
return client.GetConfigurationOptions();
}
finally
{
client.Close();
}
He cambiado la configuración del registro para permitir más conexiones salientes:
MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.
Recientemente, recientemente probé SvcTraceViewer.exe. Logré atrapar una excepción en el extremo del cliente. Veo que su duración es de 1 minuto. Al observar el rastreo del lado del servidor, puedo ver que el servidor no tiene conocimiento de esta excepción. La duración máxima que puedo ver es de 10 segundos.
He examinado las conexiones de bases de datos activas usando exec sp_who en el servidor. Solo tengo unos pocos (2-3). He examinado las conexiones TCP de un cliente usando TCPview. Por lo general, es alrededor de 2-3 y he visto hasta 5 o 6.
En pocas palabras, estoy perplejo. He intentado todo lo que pude encontrar y me falta algo muy simple que un experto de WCF podría ver. Es mi intuición de que algo está bloqueando a mis clientes en el nivel bajo (TCP), antes de que el servidor realmente reciba el mensaje y / o que algo esté poniendo en cola los mensajes en el nivel del servidor y nunca los deje procesar.
Si tiene contadores de rendimiento que debería consultar, por favor avíseme. (Indique qué valores son malos, ya que algunos de estos contadores son difíciles de descifrar). Además, ¿cómo podría registrar el tamaño del mensaje WCF? Finalmente, ¿hay alguna herramienta allí que me permita probar cuántas conexiones puedo establecer entre mi cliente y mi servidor (independientemente de mi aplicación)?
¡Gracias por tu tiempo!
Información adicional agregada el 20 de junio:
Mi aplicación WCF hace algo similar a lo siguiente.
while (true)
{
Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
Step2GetWorkUnitFromServerViaWCF();
DoWorkLocally(); // takes 5-15minutes.
Step3SendBackResultsToServerViaWCF();
}
Usando WireShark, sí vi que cuando ocurre el error, tengo cinco retransmisiones de TCP seguidas de un reinicio de TCP más adelante. Supongo que el RST viene de WCF matando a la conexión. El informe de excepción que recibo proviene del paso 3 de tiempo de espera.
Descubrí esto mirando la secuencia de tcp "tcp.stream eq 192". Luego expandí mi filtro a "tcp.stream eq 192 y http y http.request.method eq POST" y vi 6 POST durante esta transmisión. Esto me pareció extraño, así que lo verifiqué con otra secuencia como tcp.stream eq 100. Tuve tres POST, lo que parece un poco más normal porque estoy haciendo tres llamadas. Sin embargo, cierro mi conexión después de cada llamada a WCF, por lo que esperaba una llamada por transmisión (pero no sé mucho sobre TCP).
Investigando un poco más, descargué la carga del paquete http en el disco para ver en qué se encontraban estas seis llamadas.
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2
Supongo que dos clientes concurrentes están usando la misma conexión, es por eso que vi duplicados. Sin embargo, todavía tengo algunos problemas más que no puedo comprender:
a) ¿Por qué el paquete está dañado? Racha de red aleatoria, ¿tal vez? La carga se gzip usando este código de ejemplo: http://msdn.microsoft.com/en-us/library/ms751458.aspx - ¿Podría el código tener errores de vez en cuando cuando se usa al mismo tiempo? Debería probar sin la biblioteca gzip.
b) ¿Por qué vería que se ejecutan los pasos 1 y 2 DESPUÉS de que se agotó el tiempo de espera de la operación dañada? Me parece que estas operaciones no deberían haber ocurrido. Tal vez no estoy buscando el flujo correcto porque mi comprensión del TCP es defectuosa. Tengo otras transmisiones que ocurren al mismo tiempo. Debería investigar otras transmisiones: un vistazo rápido a las transmisiones 190-194 muestra que la POST de Step3 tiene datos de carga útil adecuados (no están dañados). Empujándome a mirar la biblioteca gzip nuevamente.
¿ clientVia usar clientVia para ver el mensaje enviado, utilizando el kit de herramientas SOAP o algo así? Esto podría ayudar a ver si el error proviene del propio cliente o de otro lugar.
¿Estás cerrando la conexión al servicio WCF entre las solicitudes? Si no lo hace, verá este tiempo de espera exacto (eventualmente).
¿Revisaste las huellas de WCF? WCF tiene una tendencia a tragarse excepciones y solo devuelve la última excepción, que es el tiempo de espera que está recibiendo, ya que el punto final no devolvió nada significativo.
Acabo de resolver el problema. Descubrí que los nodos en el archivo App.config se han confundido.
<client>
<endpoint name="WCF_QtrwiseSalesService" binding="wsHttpBinding" bindingConfiguration="ws" address="http://cntgbs1131:9005/MyService/TGE.ISupplierClientManager" contract="*">
</endpoint>
</client>
<bindings>
<wsHttpBinding>
<binding name="ws" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
<**security mode="None">**
<transport clientCredentialType="None"></transport>
</security>
</binding>
</wsHttpBinding>
</bindings>
Confirme su configuración en el nodo <security> , el valor de "modo" de atributo es "Ninguno". Si su valor es "Transporte", se produce el error.
Estoy teniendo un problema muy similar. En el pasado, esto se ha relacionado con problemas de serialización. Si todavía tiene este problema, puede verificar que puede serializar correctamente los objetos que está devolviendo. Específicamente, si está utilizando objetos Linq-To-Sql que tienen relaciones, existen problemas de serialización conocidos si coloca una referencia retrospectiva en un objeto secundario al objeto primario y marca esa referencia posterior como un DataMember.
Puede verificar la serialización escribiendo una aplicación de consola que serialice y deserialice sus objetos utilizando DataContractSerializer en el lado del servidor y los métodos de serialización que use su cliente. Por ejemplo, en nuestra aplicación actual, tenemos clientes WPF y Compact Framework. Escribí una aplicación de consola para verificar que puedo serializar usando un DataContractSerializer y deserializar usando un XmlDesserializer. Puedes intentar eso.
Además, si devuelve objetos Linq-To-Sql que tienen colecciones secundarias, puede intentar asegurarse de que los haya cargado ansiosamente en el servidor. A veces, debido a la carga diferida, los objetos que se devuelven no se rellenan y pueden causar que el comportamiento que está viendo donde se envía la solicitud al método de servicio varias veces.
Si has resuelto este problema, me encantaría saber cómo porque también estoy atascado. He verificado que mi problema no es la serialización, así que estoy perdido.
ACTUALIZACIÓN: no estoy seguro de si te ayudará pero la herramienta Service Trace Viewer Tool acaba de resolver mi problema después de 5 días de experiencia muy similar a la tuya. Al configurar el seguimiento y luego mirar el XML sin procesar, encontré las excepciones que causaban mis problemas de serialización. Se relacionó con objetos Linq-to-SQL que ocasionalmente tenían más objetos secundarios de los que podrían serializarse con éxito. Agregar lo siguiente a su archivo web.config debería permitir el rastreo:
<sharedListeners>
<add name="sharedListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:/Temp/servicetrace.svclog" />
</sharedListeners>
<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
<listeners>
<add name="sharedListener" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="sharedListener" />
</listeners>
</source>
</sources>
El archivo resultante se puede abrir con la herramienta Visor de rastreo de servicio o solo en IE para examinar los resultados.
No soy un experto en WCF, pero me pregunto si no se está ejecutando una protección DDOS en IIS. Sé por experiencia que si ejecuta un montón de conexiones simultáneas de un solo cliente a un servidor en algún momento el servidor deja de responder a las llamadas, ya que sospecha un ataque DDOS. También mantendrá las conexiones abiertas hasta que se agote el tiempo de espera para ralentizar al cliente en sus ataques.
Sin embargo, la conexión múltiple proveniente de diferentes máquinas / IP no debería ser un problema.
Hay más información en esta publicación de MSDN:
http://msdn.microsoft.com/en-us/library/bb463275.aspx
Eche un vistazo a la propiedad MaxConcurrentSession.
Parece que este mensaje de excepción es bastante genérico y se puede recibir debido a una variedad de razones. Nos encontramos con esto al implementar el cliente en máquinas con Windows 8.1. Nuestro cliente WCF se ejecuta dentro de un servicio de Windows y continuamente sondea el servicio WCF. El servicio de Windows se ejecuta bajo un usuario que no es administrador. El problema se solucionó estableciendo clientCredentialType en "Windows" en la configuración de WCF para permitir la autenticación a través de la transferencia, como se muestra a continuación:
<security mode="None">
<transport clientCredentialType="Windows" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
Puede ayudarte este enlace en Msdn Blogs:
Si aún no lo ha intentado, encapsule las operaciones WCF del lado del servidor en los bloques try / finally y agregue el registro para asegurarse de que realmente regresen.
Si esos muestran que las Operaciones se están completando, entonces mi siguiente paso sería ir a un nivel inferior y observar la capa de transporte real.
Wireshark u otra herramienta similar de captura de paquetes puede ser muy útil en este punto. Supongo que esto se está ejecutando a través de HTTP en el puerto estándar 80.
Ejecute Wireshark en el cliente. En las Opciones, cuando inicie la captura, configure el filtro de captura en tcp http and host service.example.com ; esto reducirá la cantidad de tráfico irrelevante.
Si puede, modifique a su cliente para que le notifique la hora exacta de inicio de la llamada y la hora en que se produjo el tiempo de espera. O simplemente monitorearlo de cerca.
Cuando obtiene un error, puede rastrear los registros de Wireshark para encontrar el inicio de la llamada. Haga clic con el botón derecho en el primer paquete que tiene su cliente llamando (debe ser algo como GET /service.svc o POST /service.svc) y seleccione Follow TCP Stream.
Wireshark decodificará toda la conversación HTTP, por lo que puede asegurarse de que WCF realmente envíe respuestas.
Si está utilizando el cliente .Net, es posible que no haya establecido
//This says how many outgoing connection you can make to a single endpoint. Default Value is 2
System.Net.ServicePointManager.DefaultConnectionLimit = 200;
aquí está la pregunta y respuesta originales WCF Service Throttling
Actualización :
Esta configuración entra. La aplicación del cliente .Net puede estar en el inicio o siempre, pero antes de comenzar las pruebas.
Además, puedes tenerlo en el archivo app.config así como seguir
<system.net>
<connectionManagement>
<add maxconnection = "200" address ="*" />
</connectionManagement>
</system.net>
También recibirá este error si está devolviendo un objeto al cliente que contiene una propiedad de tipo enum que no está configurada de manera predeterminada y que enum no tiene un valor que se enum MyEnum{ a=1, b=2}; a 0. ie enum MyEnum{ a=1, b=2};
desde: http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx
Para evitar este error de tiempo de espera, debemos configurar la propiedad OperationTimeout para Proxy en el código del cliente WCF. Esta configuración es algo nuevo a diferencia de otras configuraciones como Enviar tiempo de espera, Tiempo de espera de recepción, etc., que discutí al principio del artículo. Para establecer la configuración de la propiedad de tiempo de espera de esta operación, debemos convertir nuestro proxy en IContextChannel en la aplicación cliente WCF antes de llamar a los métodos de contrato de operación.