Nginx reverse proxy + mongrel and fork

[Ezra Zygmuntowicz]

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  
> finished.
> At this point, nginx should return the response immediately, but it
> doesn't.
>
>> 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/2.0.0.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/2.0.0.11" "-" 1.881 1.881
>
> The first line is requesting the long running action (which calls  
> fork.)
> 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:  
> Operation
> 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:
> "http://localhost/admin/categories/products"
>
> Thanks!

	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:

http://codeforpeople.rubyforge.org/svn/bj/trunk/README

Cheers-

- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ezra at engineyard.com
-- EngineYard.com