Passengerを使用したリクエストが失敗した後の502BadGatewayエラー
Rails 3.1 under Passenger 3.0.9）を使用してnginx 1.0.5を実行しているステージングサーバーがあります。問題は、アプリケーションエラーが発生した直後に送信されたリクエストが502 Bad Gatewayを返すことです。テストするにはダミーの例外を発生させるだけのアクションを備えた単純なコントローラーをセットアップしました。1つのリクエストではRailsエラーメッセージが表示され、次のリクエストではnginx 502 Bad Gatewayエラーが表示され、その後戻ります。 Railsアプリケーションエラーなど.
この問題を調査しているときに、アプリケーションの負荷テスト（アプリケーションプロセスの数が増える）によってその問題が消えることがわかりました。つまり、余分なプロセスがシャットダウンされるまで、その後再び表示されます。 passenger_min_instancesオプションを設定しようとしましたが、何も変更されません。この場合、アプリケーションエラーが発生するたびに、1つのインスタンスが強制終了され、負荷テスト後にすべてのインスタンスが存続します。
追伸：私のチームの何人かの人々は、アプリケーションエラーがなくても502エラーが発生したと言っていましたが、それを再現することはできませんでした。
更新：abを使用して応答ステータスコードを表示する方法を見つけました。それらのほとんどは502です！
私はついに本当の問題が何であるかを見つけました。まず、この問題を調査しているときに、Passangerがエラーメッセージをnginx内部エラーログに記録していることを知りました。サーバーの/var/logにあるものではなく、/usr/local/nginx/logs/error.logにあります。したがって、私が受け取った実際のエラーメッセージは次のとおりです。
Exception ThreadError in application (deadlock; recursive locking) (process 6407, thread #<Thread:0x89e5ef0>):
from /var/www/fantasy-sports/shared/bundle/Ruby/1.9.1/gems/rack-1.3.2/lib/rack/lock.rb:14:in `lock'
...
この問題の詳細については、こちらをご覧ください： https://github.com/rtomayko/rack-cache/issues/2
結局、私はconfig.threadsafe!ファイルのenvironments/*.rbオプションのコメントを外すことでそれを解決しました。