ruby-on-rails - read - passenger rails

Desconexión/tiempo de espera de HTTP entre la solicitud y el manejo de respuesta

Question

Supongamos el siguiente escenario:

1. El cliente está enviando HTTP POST al servidor
2. La solicitud es válida y ha sido procesada por el servidor. Los datos se han insertado en la base de datos.
3. La aplicación web responde al cliente
4. El cliente cumple el tiempo de espera y no ve la respuesta HTTP.

En este caso nos encontramos con una situación donde: - el cliente no sabe si sus datos fueron válidos y se insertaron correctamente - el servidor web (aplicación Rails 3.2) no muestra ninguna excepción, no importa si está detrás del proxy apache o no

No puedo encontrar cómo manejar dicho escenario en la documentación de HTTP. Mi pregunta es:

a) ¿Debería el cliente esperar que sus datos SE PUEDAN procesar ya? (Por lo tanto, intente, por ejemplo, solicitar GET para verificar si se han enviado datos)

b) si no (a) - ¿Debería el servidor detectarlo? ¿hay posibilidad de hacerlo en rieles? En tal caso, los cambios se pueden revertir. En tal caso, esperaría algún tipo de aplicación expection of rails pero no hay ...

Answer 1

Puede manejar esto con ajax y jQuery ya que la documentación de la devolución de llamada completa se explica a continuación:

Completar

Tipo: Función (jqXHR jqXHR, String textStatus)

Una función que debe invocarse cuando finaliza la solicitud (después de que se ejecutan las devoluciones de llamada correctas y de error). La función recibe dos argumentos: el objeto jqXHR (en jQuery 1.4.x, XMLHTTPRequest) y una cadena que categoriza el estado de la solicitud ("éxito", "no modificado", "error", "tiempo de espera" , "abortar" o "parsererror").

Jquery ajax API

En cuanto a su segunda pregunta, está fuera manejar esto a través de rieles, la respuesta es no, ya que el tiempo de espera es del lado del cliente y no del servidor, sin embargo, para revertir los cambios sugiero usar uno de los siguientes para detectar que el usuario aún está en línea o no

1. http://socket.io/
2. websocket-rails

Answer 2

HTTP es un protocolo sin estado : lo que significa que, por definición, no se puede saber por el lado del cliente que el POST http-verb ha tenido éxito o no.

Existen algunas técnicas que las aplicaciones web usan para superar esta ''característica'' HTTP. Incluyen.

• sesiones de servidor
• galletas
• variables ocultas dentro del formulario

Sin embargo , ninguno de estos realmente te ayudará con tu problema. Cuando me encontré con este tipo de problemas en el pasado, casi siempre son el resultado de que el servidor tarda demasiado en procesar la solicitud web .

Hay una muy buena cita para eso, me susurro a mí mismo en las noches de insomnio:

"La solicitud web es un lugar aterrador, quieres entrar y salir lo más rápido que puedas" - Rick Branson

Desea entrar y salir de su solicitud web en 100 - 500 ms. Cumples esos números y tendrás una aplicación web que se comportará bien / jugará bien con los servidores web.

Con ese fin , le sugiero que investigue cuánto tiempo están tomando sus publicaciones y descubra cómo acortar esas solicitudes . Si está realizando un procesamiento serio en el lado del servidor antes de hacer las inserciones de dbms, debería considerar entregarlas a algún tipo de sistema de tareas / colas.

Un ejemplo de "procesamiento serio" podría ser algún tipo de carga de imágenes, posiblemente con algún procesamiento de imágenes después de la carga. Un ejemplo de una solución de tareas y colas sería: RabbitMQ y Apio

Una solución de ejemplo para su problema podría ser:

1. inserte una parte de sus datos en los dbms (o incluso más rápidamente alguna solución NoSQL )
2. transferir el costoso procesamiento a una tarea en segundo plano.
3. regresar al usuario / web-cliente. (incluso en el fondo, la tarea aún se está ejecutando)
4. escuche la respuesta final con ( sondeo, transmisión o websockets ). Este paso no es una tarea trivial, pero el resultado final bien vale la pena.

Ajuste la solicitud web y será raro que su cliente no reciba una respuesta.

En ese raro día en que el cliente no recibe los datos : ¿Cómo se previenen varias publicaciones? No sé nada sobre sus datos. Sin embargo, hay algunas cosas relacionadas con el esquema que puede hacer para identificar su publicación de manera única. es decir, averiguar en el lado del servidor si los datos son una update o una create .

Esta respuesta cubre algunas de las técnicas de sondeo / transmisión / websocket que puede usar.