У меня есть промежуточный сервер под управлением nginx 1.0.5 с использованием Rails 3.1 под Passenger 3.0.9. Проблема в том, что запрос, отправленный сразу после того, как возвращается ошибка приложения 502 Bad Gateway. Чтобы проверить это, я настроил простой контроллер с действием, которое просто вызывает фиктивное исключение. Один запрос покажет сообщение об ошибке Rails, а следующий - nginx 502 Bad Gateway ошибка, затем возвращается ошибка приложения Rails и т. д.
Изучая эту проблему, я обнаружил, что нагрузочное тестирование приложения (увеличивающее количество процессов приложения) устраняет эту проблему. То есть до тех пор, пока не будут отключены лишние процессы, а затем снова появится. Я пробовал установить passenger_min_instances вариант, но это ничего не меняет, и в этом случае каждый раз, когда происходит ошибка приложения, один экземпляр уничтожается, а после нагрузочного тестирования все экземпляры остаются в живых.
P.S .: Некоторые люди в моей команде сказали мне, что они видели ошибку 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/23
В конце концов я решил это, раскомментировав config.threadsafe! вариант в environments/*.rb файлы.