Nginx returns 502 and drops the next request without checking upstream
Sudara
swilliams at engineyard.com
Tue Sep 23 12:30:04 MSD 2008
For anyone else looking at this issue, the following is an answer:
upstream name_of_upstream{
server 127.0.0.1:5000 fail_timeout=0;
server 127.0.0.1:5001 fail_timeout=0;
}
fail_timeout gives you control over how nginx considers an upstream
inoperative.
Take a gander here for more information.
http://wiki.codemongers.com/NginxHttpUpstreamModule
Thanks,
Sudara
On Sep 22, 2008, at 10:38 AM, Sudara wrote:
> Hi guys,
>
> 1. I have Nginx proxying upstream to 3 mongrels
>
> 2. A request comes in that has a ridiculous and crazy URL
>
> 3. The url is passed to the mongrels, and each mongrel errors on the
> request (Mongrel::HttpParserError: Invalid HTTP format, parsing
> fails.)
>
> 4. Nginx tries each mongrel in the upstream, gets the same result
> from each ( http://pastie.textmate.org/private/
> m9xjf7elqtmb2kwdtsbaa ) and passes a 502 to the client.
>
> 5. On the next request, Nginx never tries the upstream. Nginx
> returns a 502 for this next without checking the upstream. In this
> case, a real request is lost because (maybe) Nginx thinks that the
> upstream is invalid. See my strace:
> http://pastie.org/private/0ktyhglwvmpwjbocryfysg and see the entire
> sequenced logged http://pastie.textmate.org/private/za2vqdrbxy8paoqfx1mlmq
>
> Is this correct nginx behavior? Is mongrel giving an incorrect
> response to nginx?
>
> Thanks for your help,
> Sudara
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080923/456535a8/attachment.html>
More information about the nginx
mailing list