<meta http-equiv="content-type" content="text/html; charset=utf-8">> Do you mean "backup" as in "server ... backup;" in upstream definition?<br><br><div>I do. And thank you for the detailed reply -- this was exactly the information I was looking for!</div>
<div><br></div><div>Cheers,</div><div>-steven</div><div><br></div><div><br><div class="gmail_quote">On Wed, May 18, 2011 at 3:00 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello!<br>
<div class="im"><br>
On Wed, May 18, 2011 at 02:35:49PM -0500, Steven Deobald wrote:<br>
<br>
> Hey folks,<br>
><br>
> We've got the following scenario occurring in production. The solution is<br>
> non-obvious... to me, at least.<br>
><br>
> [client] ==> [nginx] ==> [service S]<br>
><br>
> * nginx fronting 2 application servers which provide a service S. (Primary<br>
> and backup, both running Trinidad. Trinidad is a JRuby/Rails wrapper for<br>
> Tomcat.)<br>
<br>
</div>Do you mean "backup" as in "server ... backup;" in upstream<br>
definition?<br>
<div class="im"><br>
> * hot-deploying a rails (jruby) app into Trinidad causes Trinidad to return<br>
> a 404 to nginx<br>
> * nginx returns the 404 to the application. In this particular case, the<br>
> client is another service which expects service S to remain live during<br>
> deployments<br>
><br>
> So, nginx does provide an "http_404" case for the "proxy_next_upstream"<br>
> directive. However, this would require the "max_fails" setting to pertain to<br>
> 404s, which it doesn't... otherwise legitimate 404s produce an infinite<br>
> loop.<br>
><br>
> Is there something like "max_fails" for 404s?<br>
> Is there another solution to this problem?<br>
> Is it Trinidad's fault for returning 404s and not 503s? (I would say it is<br>
> but I can't find a solution to that problem just yet.)<br>
<br>
</div>Parameter max_fails is to mark backends down, and you probably<br>
don't want to mark backends down just because of some<br>
real/legitimate 404's.<br>
<br>
On the other hand, using "server ... backup" indeed will cause<br>
infinite loop with "proxy_next_upstream http_404". It's a bug, it<br>
should only ask each backend once.<br>
<br>
Workaround is to don't use "server ... backup" but use either<br>
"weight=" instead (big one for real server, small one for backup<br>
one) or use error_page-based fallback instead.<br>
<font color="#888888"><br>
Maxim Dounin<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://nginx.org/mailman/listinfo/nginx" target="_blank">http://nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>