Tenemos un montón de servicios de WCF que funcionan casi todo el tiempo, usando varios enlaces, puertos, tamaños máximos, etc. Lo súper frustrante de WCF es que cuando (rara vez) falla, somos incapaces de descubrir por qué falló. A veces obtendrá un mensaje que tiene este aspecto:Los tiempos de espera de WCF son una pesadilla
System.ServiceModel.CommunicationException: La conexión de socket fue abortado. Esto podría ser causado por un error procesando su mensaje o un tiempo de espera excedido por el host remoto , o un problema de red subyacente . El tiempo de espera del socket local fue '01: 00: 00 '. ---> System.IO.IOException: no se pueden leer datos de la conexión de transporte: una conexión existente fue forzosamente cerrada por el host remoto.
El problema es que el tiempo de espera del socket local que le da es simplemente un intento de ser conveniente. Puede o no ser la causa del problema. Pero está bien, a veces las redes tienen problemas. No es gran cosa. Podemos volver a intentarlo o algo. Pero aquí está el gran problema. Además de no decirle exactamente qué tiempo de espera (si lo hubo) resultó en la falla ("su tiempo de espera de recepción del servidor fue excedido", o algo así, sería útil), WCF parece tener dos tipos de tiempos de espera.
Tiempo de espera Tipo # 1) Un tiempo de espera, que, si aumenta, podría aumentar las probabilidades de éxito de su operación. Entonces, el tiempo de espera pertinente es de una hora, estás cargando un archivo enorme que demorará una hora y veinte minutos. Falla. Aumenta el tiempo de espera, tiene éxito. No tengo ningún problema con este tipo de tiempo de espera.
Tiempo de espera Tipo # 2) Un tiempo de espera, que se limita a definir el tiempo que tiene que esperar a que el servicio a fallar en realidad y le dará un error, pero modificando el valor de este tiempo de espera no tiene impacto en la posibilidad de éxito. Básicamente, algo sucede durante el primer segundo de la solicitud de servicio, lo que arruina las cosas. Nunca se recuperará. WCF no vuelve mágicamente a intentar la conexión de red por usted. Bien, a veces establecer una conexión de red no funciona bien. Pero, si su tiempo de espera es de 2 horas, tiene que esperar 2 horas completas sin posibilidad de que funcione antes de que finalmente reconozca que no funcionó y le da el error.
Pero el error que ve en ambos casos es el mismo. Con tiempo de espera Tipo # 2, todavía parece que se está ejecutando un tiempo de espera. Sin embargo, podría aumentar todos sus tiempos de espera a 4 años, y todo lo que haría es tardar 4 años en recibir un mensaje de error. Sé que existe el Tipo 2 porque puedo realizar una operación que se sabe que se completa en menos de un minuto cuando tiene éxito, y tardan 2 horas en fallar. Pero, si lo mato y lo vuelvo a intentar, lo consigue rápidamente. (Si se pregunta por qué puede haber un tiempo de espera de 2 horas en una operación que demora menos de un minuto, hay ocasiones en que ejecuto la operación con un archivo mucho más grande y podría demorar más de una hora.)
Entonces, para combatir el problema con el Tipo 2, querrá que su tiempo de espera sea realmente rápido para que sepa de inmediato si hay un problema. Entonces puedes volver a intentarlo. Pero el problema insuperable es que, debido a que no sé qué tiempos de espera son la causa de la falla, no sé qué tiempos de espera son Tipo # 1 y cuáles son Tipo # 2. Puede haber un tiempo de espera (digamos el tiempo de espera de envío del lado del cliente) que actúa como Tipo N. ° 1 en algunos casos y Tipo n. ° 2 en otros. No tengo idea, y no tengo forma de averiguarlo.
¿Alguien sabe cómo rastrear los tiempos de espera de tipo 2 para que pueda establecerlos en valores bajos sin tener que acortar los tiempos de espera reales (leer: Tipo n.º 1) y reducir las posibilidades de éxito?
Gracias.
Aclaración de Tipo # 2 tiempos de espera en respuesta al comentario de Andrew Anderson:
Mi creencia es que algo va mal entre la solicitud del cliente y el código de comenzar a ejecutar en el servidor. En todos los casos donde tenemos el código del servidor indica progreso parcial, nunca termina una parte de la operación sin terminar todo. Por lo tanto, el código del servidor nunca se ejecuta, y el tiempo que llevaría la ejecución es irrelevante (aparte de que afecta a lo que establecimos nuestros valores de tiempo de espera en primer lugar para acomodarlo).
Se solicitó una aclaración en el tiempo de espera del tipo 2: ¿Qué está fallando? ¿El código del lado del servicio, o algo así, entre solicitar una conexión al cliente y, en realidad, comenzar a ejecutar su llamada de método en el lado del servicio? –
¿Puede dar una simple descripción paso a paso de esos tipos de "Tipo 2" y la configuración exacta de enlace a la que se refiere? – Alex
Este problema es similar entre la gestión de proyectos (como clientes) y los desarrolladores (como servicios). Cada vez que se excede el tiempo de espera, la gerencia del proyecto quiere saber si se trata de un tipo 1 o tipo 2. Sin embargo, los desarrolladores no saben (aún no han terminado), por lo que no pueden asesorar. –