0x80004005 asp.net httpexception request-timed-out

asp.net - httpexception(0x80004005)



Diagnosticando "Tiempo de espera de la solicitud expirada" HttpExceptions (7)

¿Has intentado publicar manualmente a través de telnet y simplemente no completar el POST? Me interesaría ver si puedes replicar el comportamiento que estás viendo. Dada la naturaleza del sitio, no me sorprendería que obtuviera algunos POST mal formados intencionalmente para intentar hackear el sistema.

He notado en ocasiones que necesito reiniciar Safari para que SO vuelva a funcionar después de que se cuelguen algunas acciones, pero asumí que era mi problema.

Aquí en StackOverflow, estamos viendo algunas excepciones de "Tiempo de espera agotado para la solicitud" todos los días.

Los hechos:

  • El tiempo de espera de solicitud es el predeterminado 90 segundos
  • Ocurre solo en los POST
  • Los datos publicados son texto, generalmente pequeños (<1 KB), pero pueden oscilar entre algunos KB
  • No se capturan datos de formulario en variables de servidor
  • Los UA de cliente son diversos: IE5.5 - 7, Firefox 3.0.5, iPhone, Chrome
  • Las ubicaciones de los clientes son diversas: Reino Unido, Francia, EE. UU. - NC, OH, NE, IN

Hemos probado un tiempo de espera basado en servidor (es decir, utilizando Thread.Sleep) y todas las variables de formulario se capturan correctamente en el registro de excepciones; esto nos lleva a creer que el cliente tiene problemas para enviar la solicitud en el tiempo asignado.

¡Cualquier idea sobre cómo atrapar / depurar esta condición es muy bienvenida!

Si está ejecutando IIS 7, puede usar el seguimiento de solicitudes fallidas . En realidad no lo he usado para tiempos de espera, lo he configurado principalmente para capturar códigos de error http específicos. Pero sé que puede hacer que arroje rastros de cualquier solicitud que tome más de X cantidad de tiempo.

Solíamos ver mucho con nuestro cliente web de mucho tráfico: me pregunto si está relacionado. Lo que supuestamente estaba sucediendo era HttpWebRequest (supongo que tienes problemas con HttpWebResponse? Tal vez tengan los mismos problemas) usa algún grupo de subprocesos janky debajo de las carátulas, incluso cuando tus solicitudes son sincrónicas. De vez en cuando, algo se estancaba porque algún otro objeto .NET que estuviera más arriba en la pila usaba el mismo grupo de subprocesos del sistema y uno podía privar al otro de la pila, lo que finalmente causaba un tiempo de espera. Creo que el problema se describe mejor aquí: http://www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/

También escanearía las direcciones IP en sus registros para ver si son las mismas personas las que tienen problemas repetidamente. Ya sabes, es posible que algunas personas sigan usando cuentas de acceso telefónico, o puede haber otros problemas de red en su extremo. Pero, por supuesto, no solo lo borre sin investigar tanto como pueda.

Estamos experimentando el mismo problema de "Solicitud agotada" con nuestros servidores web después de cambiar de IIS6 a IIS7. Creo que el problema es específico de IIS7. Supongo que estos errores fueron eliminados o ignorados más arriba en la cadena de procesamiento en IIS6, antes de que la solicitud fuera entregada a ASP.Net para su procesamiento. Estoy activando el seguimiento de solicitudes fallidas hoy para ver si puedo capturar más información sobre el problema. Hasta ahora parece que su explicación de las causas del lado del cliente parece ser la más válida.

Tengo el mismo problema en nuestros servidores de producción que usan un pequeño servicio web AJAX. Después de realizar capturas de paquetes fuera de nuestro firewall, descubrimos que el POST del servicio venía en dos segmentos TCP y el segundo segmento nunca llegó a nosotros. (el primer paquete solo contiene encabezados, el segundo paquete faltante debe ser el cuerpo json) Entonces, básicamente, IIS está sentado allí esperando el resto del POST. Después del tiempo de espera configurado, el servidor envía un paquete RST al cliente y registra el error "Tiempo de espera agotado para la solicitud", que es el comportamiento correcto.

Estamos tratando de obtener un cliente repro sin mucha suerte, pero en nuestro caso esto parece estar completamente relacionado con la red (o posiblemente algún software de "seguridad" que no le gusta el contenido de la publicación).