python - r15 - heroku free app running time quota exhausted

¿Heroku trunca las respuestas HTTP?

Question

Estoy ejecutando una aplicación Flask / Gunicorn Python en un díno Heroku Cedar. La aplicación devuelve JSON responses a sus clientes (en realidad es un API server ).

De vez en cuando, los clientes obtienen respuestas de 0 bytes. Sin embargo, no soy yo quien los devuelve. Aquí hay un fragmento del registro de mi aplicación:

14 de mar 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app [web.1] [2013-03-14 13:13:31 UTC] 10.104.41.136 apisrv - api_get_credits_balance (): session_token = [MÁSCARA ]

La primera línea de arriba es yo comenzando a manejar la solicitud.

14 de mar 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app [web.1] [2013-03-14 13:13:31 UTC] 10.104.41.136 apisrv 1252148511 api_get_credits_balance (): return [{'' credits_balance '': 0}]

La segunda línea es que yo devuelva un valor (a Frasco - es un objeto Frasco "Respuesta").

14 de mar 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app [web.1] "10.104.41.136 - - [14 / Mar / 2013: 13: 13: 31]" POST / get_credits_balance? Session_token = MASKED HTTP / 1.1 "200 22" - "" Appcelerator Titanium / 3.0.0.GA (iPhone / 6.1.2; iPhone OS; en_US;) "

La tercera línea es Gnicorn, donde se puede ver que el Gunicorn obtuvo el estado 200 y el cuerpo HTTP de 22 bytes (" 200 22 ").

Sin embargo, el cliente obtuvo 0 bytes. Aquí está el registro del enrutador Heroku:

14 de marzo 13:13:30 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku [router] at = método de información = POST path = / get_credits_balance? Session_token = MASKED host = matchspot-apisrv.herokuapp.com fwd = "66.87. 116.128 "dyno = web.1 queue = 0 wait = 0ms connect = 1ms service = 19ms estado = 200 bytes = 0

¿Por qué Gunicorn devuelve 22 bytes, pero Heroku ve 0 y, de hecho, devuelve 0 bytes al cliente? ¿Es esto un error de Heroku?

Answer 1

Sé que se me puede considerar un poco extraño aquí, pero hay otra opción.

Sabemos que de vez en cuando hay un error que ocurre en el tránsito. Sabemos que no hay mucho que podamos hacer ahora para detener el problema. Si solo proporciona la API, deje de leer; sin embargo, si también escribe el cliente, continúe.

El error es un caso conocido y una causa conocida. El resultado de un valor de retorno vacío significa que algo salió mal. Sin embargo, el valor está disponible y fue captado, calculado, lo que sea ... Mi instinto como desarrollador sería tratar un resultado vacío como un error de HTTP y solicitar que los datos sean reenviados. Luego puede hacer un seguimiento de las solicitudes de reenvío y ver con qué frecuencia sucede esto.

Sugeriría (aunque me parece que también soy el tipo de desarrollador que piense en esto) que cuente las solicitudes y establezca un valor razonable para responder al "error de red" al usuario. Mi instinto sería volver a intentarlo de inmediato y luego esperar un poco antes de volver a intentarlo.

De lo que describes, el primer intento probablemente recogería los datos correctamente. Por supuesto, esto podría significar mantener las solicitudes más antiguas en caché durante unos minutos o ejecutar la solicitud por segunda vez, dependiendo de lo que parezca más apropiado.

Esto también redirigiría a cualquier cantidad de otros errores de red punto a punto y dejaría la aplicación mucho más robusta incluso frente a problemas de conectividad.

Sé que nuestro instinto como desarrolladores es corregir la falla conocida, pero a veces es mejor trabajar hacia un sistema que sea capaz de operar a pesar de las fallas. Dicho esto, nunca está de más registrar los errores y problemas y tratar de solucionarlos de todos modos.