78

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}]

2行目は値を返しています（Flaskに-それはFlaskの「応答」オブジェクトです）。

3 月 14 日 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;)"

3 行目は Gnicorn のもので、Gunicorn が 200 ステータスと 22 バイトの HTTP 本文 (" 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 のバグですか?

4

1 に答える 1

1

私はここで少し壁から外れていると考えられるかもしれませんが、別のオプションがあります.

時々、輸送中にバグが発生することがあります.問題を止めるために今できることはあまりないことを知っています. API のみを提供する場合は読むのをやめてください。ただし、クライアントも作成する場合は読み続けてください。

エラーは既知のケースであり、既知の原因です。空の戻り値の結果は、何かがうまくいかなかったことを意味します。ただし、値は利用可能であり、フェッチされ、計算されました...開発者としての私の本能は、空の結果をHTTPエラーとして扱い、データの再送信を要求することです。その後、再送信リクエストを追跡して、これがどのくらいの頻度で発生するかを確認できます。

リクエストを数えて、ユーザーに「ネットワーク エラー」を返すための適切な値を設定することをお勧めします (ただし、これについても考えるような開発者だと思います)。私の本能は、すぐに再試行し、少し待ってからもう一度再試行することです.

あなたが説明したことから、最初の再試行はおそらくデータを適切に取得するでしょう。もちろん、これは古いリクエストを数分間キャッシュに保持したり、最も適切と思われるものに応じて再度リクエストを実行したりすることを意味します。

これにより、他のポイント ツー ポイント ネットワーキング エラーがいくつでも回避され、接続の問題が発生した場合でもアプリの堅牢性が大幅に向上します。

既知の障害を修正することが開発者としての私たちの本能であることはわかっていますが、障害が発生しても動作できるシステムに向けて作業した方がよい場合もあります。とはいえ、エラーや問題をログに記録し、とにかくそれらを修正しようとすることは決して悪いことではありません。

于 2013-05-16T10:17:31.973 に答える