502 Erro de gateway inválido após solicitações com falha usando o Passenger

Question

Eu tenho um servidor de teste executando o nginx 1.0.5 usando o Rails 3.1 no Passenger 3.0.9. O problema é que uma solicitação enviada logo depois de uma onde há um erro de aplicativo retorna 502 Bad Gateway . Para testá-lo eu configurei um controlador simples com uma ação que apenas levanta uma exceção fictícia. Uma solicitação mostrará a mensagem de erro do Rails e a próxima mostrará o erro nginx 502 Bad Gateway , depois retornará ao erro do aplicativo Rails, etc.

Ao investigar esse problema, descobri que o teste de carga do aplicativo (que aumenta o número de processos de aplicativos) faz com que esse problema desapareça. Isso é até que os processos extras sejam desligados, então reaparecem. Eu tentei definir a opção passenger_min_instances , mas isso não muda nada e, nesse caso, cada vez que um erro de aplicativo ocorre, uma instância é eliminada e, após o teste de carga, todas as instâncias são mantidas ativas.

P.S .: Algumas pessoas da minha equipe me disseram que viram o erro 502 mesmo quando não há erro de aplicativo, mas não consegui reproduzir isso.

Atualização : Acabamos de descobrir como exibir os códigos de status das respostas usando ab e a maioria deles é 502!

    

Answer 1

Eu finalmente descobri qual é o problema real . Primeiro, ao investigar esse problema, aprendi que o Passanger registra suas mensagens de erro no log de erros interno do nginx, não aquelas em /var/log , em nosso servidor está localizado em /usr/local/nginx/logs/error.log . Então, a mensagem de erro que recebi é:

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'
...

Há mais informações sobre esse problema: link

No final, resolvi-o removendo o comentário da opção config.threadsafe! nos arquivos environments/*.rb .