バックグラウンド タスクの純粋な wsgi 実装はありますか?
ブローカーを介して別のデーモンプロセスにシリアル化/逆シリアル化するのではなく、同じコンテキストでローカル変数を直接使用したい。
現在の wsgi インフラストラクチャでこれを実現することは可能ですか? たとえば、応答が返された後、いくつかのコールバック関数を実行しますか?
バックグラウンド タスクの純粋な wsgi 実装はありますか?
ブローカーを介して別のデーモンプロセスにシリアル化/逆シリアル化するのではなく、同じコンテキストでローカル変数を直接使用したい。
現在の wsgi インフラストラクチャでこれを実現することは可能ですか? たとえば、応答が返された後、いくつかのコールバック関数を実行しますか?
これは、Python WEB-SIG で尋ねられた質問の複製です。Python WEB-SIG の質問への回答として提供されたものと同じページを参照して、他の人がそれを見ることができるようにします。
http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode
ただし、これを行うと、リクエストスレッドが拘束されるため、タスクが完了するまで他のリクエストを処理できなくなります。
リクエストの最後にバックグラウンド スレッドを作成することは、タスクのワーカー スレッドの数を制限するようなプーリング メカニズムを使用しない限り、お勧めできません。プロセスがクラッシュしたりシャットダウンしたりする可能性があるため、メモリ内のみでジョブが失われ、永続的ではなくなります。
Celery を使用することをお勧めします。または、重すぎると思われる場合は、代わりに Redis Queue (RQ) を検討してください。
Django async を見ることができます。データベース内キューを使用するため、トランザクションをより適切に処理します。戻り値の型と同様に、すべての引数は JSONable である必要があります。場合によっては、これはラッパー関数をスケジュールする必要があるかもしれないことを意味しますが、それは頭痛の種になるべきではありません。
http://pypi.python.org/pypi/django-async
この種のことを Web サーバー内で実行したくはありません。Web サーバー内で実行するのは絶対に適切な場所ではありません。Django async は、ループで実行できるキューをフラッシュするための manage.py コマンドを提供します。これは、Web サーバーから別のマシンで実行できます。