Heroku Cedar dyno에서 Flask / Gunicorn Python 앱을 실행하고 있습니다. 앱 반환JSON responses 이 클라이언트에게 됩니다 ( API server실제로는).
가끔 클라이언트는 0 바이트 응답을받습니다. 그러나 그것들을 돌려주는 것은 내가 아닙니다. 다음은 내 앱 로그의 일부입니다.
3 월 14 일 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 = [MASKED ]
위의 첫 번째 줄은 요청을 처리하기 시작하는 것입니다.
3 월 14 일 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 () : 반환 [{ ‘ credits_balance ‘: 0}]
두 번째 줄은 값을 반환하는 것입니다 (Flask에-Flask “Response”객체입니다).
3 월 14 일 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app [web.1] “10.104.41.136–[2013 년 3 월 14 일 : 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;) “
세 번째 줄은 Gnicorn의 것입니다. 여기에서 Gunicorn이 상태가 200이고 HTTP 본문이 22 바이트 인 것을 볼 수 있습니다 ( ” 200 22“).
그러나 클라이언트는 0 바이트를 얻었습니다. 다음은 Heroku 라우터 로그입니다.
3 월 14 일 13:13:30 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku [router] at = info method = POST path = / get_credits_balance? session_token = MASKED host = matchspot-apisrv.herokuapp.com fwd = “66.87. 116.128 “dyno = web.1 대기열 = 0 대기 = 0ms 연결 = 1ms 서비스 = 19ms 상태 = 200 바이트 = 0
Gunicorn이 22 바이트를 반환하지만 Heroku가 0을보고 실제로 0 바이트를 클라이언트에 다시 전달하는 이유는 무엇입니까? 이것은 Heroku 버그입니까?
답변
나는 내가 여기서 벽에서 약간 벗어난 것으로 간주 될 수 있지만 다른 옵션이 있습니다.
우리는 때때로 운송 중에 발생하는 버그가 있다는 것을 알고 있으며, 문제를 막기 위해 지금 당장 할 수있는 일이 많지 않다는 것을 알고 있습니다. API 만 제공하는 경우 읽기를 중지하고 클라이언트도 작성하는 경우 계속 진행하십시오.
오류는 알려진 경우이며 알려진 원인입니다. 빈 반환 값의 결과는 문제가 발생했음을 의미합니다. 그러나 값을 사용할 수 있고 가져오고 계산했습니다. 개발자로서 내 본능은 빈 결과를 HTTP 오류로 처리하고 데이터를 다시 전송하도록 요청하는 것입니다. 그런 다음 재전송 요청을 추적하고 이것이 얼마나 자주 발생하는지 확인할 수 있습니다.
나는 당신이 요청을 세고 사용자에게 “네트워크 오류”에 응답하기위한 적절한 값을 설정하도록 제안합니다 (당신이 이것도 생각하는 종류의 개발자라고 생각하지만). 내 본능은 바로 재 시도한 다음 조금 더 기다렸다가 다시 시도하는 것입니다.
설명하는 첫 번째 재 시도에서 데이터를 올바르게 선택합니다. 물론 이것은 가장 적절한 것으로 보이는 것에 따라 오래된 요청을 몇 분 동안 캐시에 보관하거나 요청을 두 번 실행하는 것을 의미 할 수 있습니다.
이것은 또한 다른 지점 간 네트워킹 오류를 우회하여 연결 문제가 발생하더라도 앱을 훨씬 더 견고하게 만듭니다.
개발자로서의 본능은 알려진 결함을 수정하는 것이지만 때로는 결함에도 불구하고 작동 할 수있는 시스템을 향해 작업하는 것이 더 좋습니다. 그것은 오류와 문제를 기록하고 어쨌든 수정하려고 노력하는 것이 결코 아프지 않다고 말했습니다.
