2012-07-02 19 views
5

Tengo un código que extrae datos de SQL DB, luego pasa por los registros para generar una cadena, que finalmente se escribirá en un archivo de texto.Se restableció la conexión ASP.NET

El código funciona bien en mi servidor local, desde VS, pero en el servidor en vivo, después de aproximadamente un minuto y medio, aparece el error "No se recibieron datos" (chrome). El código se detiene en medio de un bucle a través de la DataTable. El soporte de alojamiento dijo que se produjo el error "Se restableció la conexión".

No estoy seguro de si se trata de un problema de tiempo de espera o qué. He establecido el executionTimeout en mi web.config (con debug = false) y no pareció ayudar. También revisé el servidor. ScriptTimeout propiedad, y que no coincide con el valor executionTimeout establecido en el web.config. Además, un tiempo de espera normalmente daría "página no disponible".

se aprecia cualquier sugerencia.

+0

la versión de servidor de Windows (IIS) es el servidor en vivo usando? –

+0

Creo que es 7.5. – Rivka

+0

He tenido el mismo problema y sucedió después de menos de un segundo. Como en tu caso, solo apareció en un servidor determinado. Resultó que solo sucedió mientras teníamos pipes ('|') en la URL de la solicitud GET. Al eliminar o codificar las tuberías, el problema ya no aparece. – chiccodoro

Respuesta

3

Parece que es el navegador que agota el tiempo de espera de una respuesta, no en el servidor. No puede controlar lo que el navegador ha establecido para esto. Lo que puedes hacer es enviar una respuesta de algún tipo al navegador, para que sepa que todavía estás cerca y no se ha bloqueado de alguna manera.

Para que esto funcione, no puede esperar hasta terminar de construir toda la cadena. Necesita volver a pensar su código para que en lugar de agregarlo a una cadena, escriba cada adición a una secuencia de salida. Esto tiene la ventaja adicional de ser una manera mucho más eficiente de crear su archivo de texto. Para mantener vivo el navegador, puede escribir cualquier cosa, siempre que algunos datos vuelvan a aparecer para que el navegador los lea. Los comentarios en HTML pueden funcionar para esto. También necesita descargar periódicamente su flujo de respuesta para que sus datos no estén almacenados en el servidor web. De lo contrario, aún podría expirar el tiempo de espera.

Por supuesto, la verdadera solución aquí es volver a pensar su diseño, de modo que su operación no tome 90 segundos más en primer lugar. Pero hasta que puedas hacer eso, espero que esto sea útil.

+0

Gracias. Si solo fuera el tiempo de espera del navegador, ¿no seguiría funcionando el servidor? En mi caso, además de que el navegador se está cerrando ahora, toda la operación también se detiene. Puedo ver esto con mis registros. – Rivka

+0

@Rivka: el navegador apaga la conexión tcp, lo que invalida la solicitud http y el servidor se detiene. –

0

suena como una tiempo de espera, podría intentar y devolver la información a través de una vista, esto sin duda aceleraría las cosas. (si es posible).

+0

La recuperación real de los datos está bien. El código pasa eso. Se agota el tiempo durante el ciclo DataTable en C#. – Rivka

5

después de aproximadamente un minuto y medio

No es su problema. Esta es una aplicación web? Un minuto y medio es muy largo tiempo para una aplicación web para responder a una solicitud. Lo suficiente como para que no valga la pena dedicarse a varios trucos para que sea una especie de trabajo.

Descargue este proceso para que sea más asíncrono con la aplicación web. La naturaleza de las aplicaciones web es que deben recibir una solicitud y responder de manera oportuna. Lo que tienes aquí es un proceso de larga duración que no puede responder de manera oportuna. La aplicación web puede facilitar las interacciones con los datos, pero no debe manejar directamente el procesamiento de los mismos en la solicitud/respuesta directamente.

¿Cómo interactúa la aplicación web con el proceso? ¿Simplemente lo inicia o proporciona información para que comience el proceso? Yo recomendaría que el proceso en sí sea manejado por algo así como un Servicio de Windows o tal vez una Aplicación de consola. Cuanto más desacoplado de la aplicación web, mejor. Ahora, dado que no sé nada sobre el proceso en sí, estoy haciendo algunas suposiciones sobre su comportamiento ...

La aplicación web puede recibir una solicitud para iniciar el proceso, junto con la información necesaria para el proceso. Puede almacenar esto en una base de datos con un valor de estado (pendiente, en cola, etc.) y luego responder al usuario (de manera oportuna) de que la solicitud se ha recibido y el proceso se ha puesto en cola. La aplicación web puede tener una página que verifique el estado para que el usuario pueda ver cómo le está yendo al proceso (si se inicia, cuántos registros ha pasado, etc.).

La aplicación fuera de línea (Servicio de Windows, et al) simplemente supervisaría esa base de datos para procesar los datos de la cola nueva. Cuando lo ve, actualiza el estado (ejecución, procesamiento, etc.) y proporciona cualquier retroalimentación relevante durante el proceso (número de registros procesados, etc.) actualizando esos datos. De modo que la aplicación fuera de línea y la aplicación web interactúan con los mismos datos, pero no de una manera que bloquee el hilo de la aplicación web y evite una respuesta para el usuario.

Cuando el proceso finaliza, el estado se actualiza nuevamente. La aplicación web puede mostrar que está terminada y proporcionar un enlace para descargar los resultados.El proceso fuera de línea incluso podría enviar un correo electrónico al usuario cuando esté terminado, o tal vez la aplicación web puede tener algún tipo de sistema de notificación (estoy imaginando los pequeños iconos de notificación en Facebook) que alertaría al usuario sobre la nueva actividad.

De esta manera, el hilo no se bloquea, el usuario puede seguir interactuando con la aplicación (incluso si hay algo con lo que interactuar), etc. Y obtiene otros beneficios adicionales, también. Por ejemplo, los resultados del proceso se guardan en la base de datos y se hace un seguimiento histórico de forma automática.

+0

De hecho, planeo hacer que esto sea asincrónico (usando ASP.NET Web API con suerte) Sin embargo, necesito una solución mientras tanto, mientras sigo yendo por esta ruta. – Rivka

0

cuando tuve este error, yo era capaz de resolverlo mediante la adición en el archivo Web.config:

<system.web> 
    <httpRuntime executionTimeout="600" maxRequestLength="51200" /> 
</system.web> 
Cuestiones relacionadas