4

Python で実装された Web サービスを使用し、Django と Piston を使用し、WSGI を介して apache サーバーで実行されている iPhone アプリがあります。

通話が終了する前に、アプリがサーバーへの接続を閉じることがあります。これを行うと、次のことが発生します。

[Tue Sep 06 11:29:46 2011] [error] [client 207.35.164.99] mod_wsgi (pid=820): Exception occurred processing WSGI script 'myscript.wsgi'.
[Tue Sep 06 11:29:46 2011] [error] [client 207.35.164.99] IOError: failed to write data

サーバーのエラーログに表示されます。

接続を明示的に閉じるのではなく、そのままにしてダウンロードを終了し、結果を無視することで、アプリの問題を「修正」できます。ただし、可能であればサーバー側でこれを修正したいと考えています。どうすればいいですか？

4

2 に答える 2

7

[免責事項: これは「簡単にできない理由」の説明であり、解決策ではありません]

@Slott が指摘したように、これは、stream.closeまたはstream.write閉じたソケットで呼び出された場合の技術的に正しい動作です。ただし、質問の動機は理解しています... wsgiアプリのコンテキストでは、クライアントが完全または部分的な読み取り後に接続を終了することは「例外的な」動作ではなく、常に発生します。未処理のままにしておくと、予想外だった/コードがこれに対して準備ができていなかったという印象が残りますが、実際には予想されており、注目に値するものではありません. だから直せばよかった。

問題は、ケースを区別する方法を見つけなければならないということです...

  • 「クライアントが 'Status: 304' を読み取った後、接続を閉じた」または「クライアントがすべてのバイトを読み取った後、接続を再利用するように要求したにもかかわらず、接続を閉じた」などの状況は、ソートを発行しないことが適切な場合です。log.debug()通話以外のロギング。

  • ただし、「ISP ルーターに脳卒中が発生したときに接続が切断されたため、クライアントがファイルの途中で読み取りを停止した」などの状況は、ログに記録されるエラーに値します。何かが正常に完了しなかったため、サーバー アプリが構築したトランザクション状態をロールバックする必要があります。その場合IOError、上向きに伝播するのが正しいことです。

このようなエラーは、エラーが発生する可能性のあるすべての場所で、これら 2 つのケースを区別するようにコードが変更されている場合にのみ、沈黙させることができます。それまでは、wsgi の作成者は注意を怠っていたようです。したがって、私が知っているこれに対する簡単な修正はありません。

（また、これはdjango固有のものではないことに注意してください.paste + pylonsを使用しても同じことが起こります）

于 2011-09-06T16:40:16.447 に答える
1

これを参照してください: http://code.google.com/p/modwsgi/issues/detail?id=29

iterable を処理している場合、メッセージはデバッグ レベルをログに記録し、Python 例外は使用されませんでした。したがって、iterable を使用したときにクライアントが閉じた接続の問題を確認するには、LogLevel をデバッグする必要があります。

どうやら、Django の応答を微調整して、文字列ではなく反復可能にする必要があるようです。

于 2011-09-06T17:39:10.853 に答える