Nginx reverse proxy + mongrel and fork
ezmobius at gmail.com
Sat Dec 22 23:23:36 MSK 2007
On Dec 22, 2007, at 11:10 AM, Nicky Be wrote:
> Aleksandar Lazic wrote:
>> 1.) what do you mean with 'immediately'?
> The rails log confirms that the mongrel (upstream) process has
> At this point, nginx should return the response immediately, but it
>> 2.) do you get the answer?
> Eventually, nginx does return the response: here are some abbreviated
> logs from a long running request:
> 127.0.0.1 - - [22/Dec/2007:13:55:33 -0500] "GET
> /admin/categories/refresh_solr/62 HTTP/1.1" 302 0
> "http://localhost/admin/categories/products" "Firefox/220.127.116.11" "-"
> 60.335 60.335
> 127.0.0.1 - - [22/Dec/2007:13:56:50 -0500] "GET /admin/categories
> HTTP/1.1" 200 2652 "http://localhost/admin/categories/products"
> "Firefox/18.104.22.168" "-" 1.881 1.881
> The first line is requesting the long running action (which calls
> After forking, it issues a redirect (the second GET). The last two
> numbers are the $request_time and $upstream_response_time.
> The nginx error log includes this entry:
> 2007/12/22 13:55:33 [error] 3730#0: *1 upstream timed out (60:
> timed out) while reading upstream, client: 127.0.0.1, server:
> nick.local, request: "GET /admin/categories/refresh_solr/62 HTTP/1.1",
> upstream: "http://127.0.0.1:3000/admin/categories/refresh_solr/62",
> host: "localhost", referrer:
I've seen this same problem with nginx and forking in mongrel/rails.
In fact I've seen the same thing with apache as well. The answer is
*do not fork* in a rails app *ever*. It will just not work and will
lead to subtle bugs exactly like what you are seeing. Give yourself a
break and do not fork a rails app.
If you need a way to kick off a long task then use this:
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
More information about the nginx