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