4

I've got a staging server running nginx 1.0.5 using Rails 3.1 under Passenger 3.0.9. The problem is that a request sent just after one where there's an application error return 502 Bad Gateway. To test it I've set up a simple controller with an action that just raise a dummy exception. One request will show the Rails error message and the next one will show nginx 502 Bad Gateway error, then it goes back to the Rails application error, etc.

While investigating this problem I've found out that load testing the application (which increase the number of application processes) make that issue disapear. That is until the extra processes are shutdown, then it reappear. I've tried setting the passenger_min_instances option, but doing so doesn't change anything and in this case each time an application error happen one instance is killed while after load testing all instances are kept alive.

P.S.: Some people on my team told me that they've seen the 502 error even when there's no application error but I've not been able to reproduce that.

Update: Just found out how to display the responses status codes using ab and most of them are 502!

1 Answer 1

1

I've finally found out what is the real problem. First, while investigating this issue I learned that Passanger log it's error messages in the nginx internal error log, not the ones in /var/log, on our server it's located at /usr/local/nginx/logs/error.log. So the actual error message I was getting is:

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

There's more information about this issue there: https://github.com/rtomayko/rack-cache/issues/23

In the end I've resolved it by uncommenting the config.threadsafe! option in the environments/*.rb files.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .