2012-09-30 71 views
6

Estoy administrando un sitio web que funciona bien durante los últimos meses en IIS 7.5 creado con MVC 3.0 ASP.net. De vez en cuando nos enfrentamos a un problema cuando falla nuestra solicitud AJAX POST (activada a través de jQuery) ya que el JSON que se está publicando se está truncando.Contenido Longitud de la solicitud de HTTP> tamaño del cuerpo

Lo que hemos encontrado hasta ahora es que, para toda solicitud de este tipo, el encabezado "Content-Length" de la solicitud tiene más datos de los que realmente recibimos en la solicitud.

Ya hemos configurado maxRequestLength a 51200 en nuestro web.config y creo que el valor de maxAllowedContentLength tiene un valor por defecto bastante grande (que no hemos establecido que en nuestra configuración). También tengo una solicitud fallida con "Content-Length" tan bajo como 7301 (bytes) pero logramos obtener solo 2179 bytes de la misma. Así que no estoy sospechando que esto esté llegando a ningún límite.

Encabezados de solicitud para una solicitud problemáticas son las siguientes

  • Cache-Control: no-cache
  • conexion: keep-alive
  • Pragma: no-cache
  • Content-Length: 7301
  • Tipo de contenido: application/json; charset = utf-8;
  • Aceptar: application/json, text/javascript, /; q = 0,01
  • Accept-Encoding: gzip, desinflar
  • Accept-Language: es-es, en; q = 0,5
  • User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv: 15.0) Gecko/20100101 Firefox/15.0.1
  • solicitada-X-Con: XMLHttpRequest

Alguna idea ??


actualización: He sido capaz de aislar aún más el problema de nuestro código. Han escrito un controlador independiente que acepta una cadena JSON y simplemente la deserializa. En caso de error, registra el error.

Cuando pulso este controlador en paralelo con 150 subprocesos concurrentes en un bucle de 50 solicitudes, recibo algunas fallas en las que se trunca el JSON que recibe este controlador. Ahora estamos fuertemente enfocados en optimizar IIS y leer más sobre varios parámetros que pueden estar relacionados (actualmente estamos ejecutando con parámetros predeterminados en IIS).

Creo firmemente que 150 conexiones simultáneas no deberían ser un gran problema y sinceramente espero que al ajustar algunos parámetros podamos superar este problema. Una vez que superemos este problema, compartiremos mis hallazgos.


* Actualización 2 (8 de octubre) *: He estrechado aún más el problema.Encendí registro de errores en IIS y descubrí que mi solicitud no obtiene el siguiente error al leer los datos

BytesReceived = 0 
ErrorCode = 2147943395 
Error Description = "The I/O operation has been aborted because of either a thread exit or an application request.(0x800703e3)" 

estoy encontrando información sobre este error en los foros de IIS, pero todavía estoy a experimentar con (mutliple) sugerencias que se dan. En el siguiente enlace puede ser un buen punto de partida para buscar más información sobre este

http://forums.iis.net/p/1149787/1917288.aspx

+0

Marque esta http://stackoverflow.com/questions/10966328/the-json-request-was-too-large-to-be -deserialized/10969382 # 10969382 – VJAI

+0

¿Tiene alguna idea de dónde se trunca el contenido? ¿Está en el navegador antes de que llegue a la llamada de Ajax? ¿Es como está escrito para la llamada de Ajax? ¿Está en la transferencia HTTP? ¿Está sucediendo en algún script del lado del servidor? – pieman72

+0

Gracias por responder chicos. @ Mark - No creo que esto esté relacionado con el tamaño de JSON (no obtengo el error de tamaño máximo mientras deserializo). Lamentablemente, no sé dónde se truncan los datos. Sé que el controlador está recibiendo datos truncados. También sé que la mayoría de las veces cuando ocurre este problema, el navegador en uso es IE 8. Todavía estoy depurando y con suerte llegaré al fondo de este problema pronto; publicaré mis hallazgos. –

Respuesta

1

finalmente me di cuenta de la causa y la solución para la solución. Desafortunadamente no es aplicable para todos mis entornos, pero ayuda al entorno de producción. Buscar detalles a continuación

Esto se debe a un error en Windows 2008 R2, donde hace que asp.net crea que un cliente se ha desconectado incluso cuando no lo ha hecho. Hay disponible una revisión para la misma y se puede encontrar en http://support.microsoft.com/kb/977453. La solución ya es parte de Windows 2008 R2 SP1 (se encuentra en here).

Mientras que la revisión funcionó para mí en un entorno que ejecuta Windows 2008 R2, no se puede aplicar a Windows 2008 R2 con SP1. Lamentablemente, el problema todavía se puede reproducir en los entornos que se ejecutan en SP1 y permanece sin resolver. Abrí un nuevo caso en los foros de IIS para este problema al http://forums.iis.net/t/1192310.aspx y lo seguiré allí.

para leer más sobre este tema - se puede seguir el hilo en http://forums.iis.net/p/1149787/1917288.aspx

+1

Estamos teniendo el mismo tipo de error, pero en Windows 2008 (no R2). Además, estoy confundido, dijiste que "la corrección ya es parte de Windows 2008 R2 SP1" y luego dices "desafortunadamente el problema todavía se puede reproducir en los entornos que se ejecutan en SP1". ? –

+0

¿Lo solucionaron? Tengo un problema muy similar ... en Windows 2008 R2 SP1, el problema persiste ... en Windows 2008 R2, aplico la revisión y todo está bien. –

Cuestiones relacionadas