Maxim Dounin Wrote:
-------------------------------------------------------
> For me, 1st google result points to author's site
> (catap.ru) with
> the patch posted alone.
>
> http://www.google.com/search?hl=en&q=upstream_coun
> t_limit
> http://catap.ru/patches/nginx/ngx_http_upstream_co
> unt_limit-0.3.patch
>

Ah, yes. I should have looked more closely. I saw the first patch, and then read the documentation for the second.

> Usually people just disable proxy_next_upstream
> (or limit it to
> something like "error") and use error_page based
> fallback instead.
> E.g.
>
> upstream backend {
> # many servers here
> }
>
> location / {
> proxy_pass http://backend;
> error_page 502 504 = @fallback;
> }
>
> location @fallback {
> proxy_pass http://backend;
> }

This is a reasonable solution for allowing only 2 maybe 3 tries. (chaining @fallback then @fallback2... etc).

After thinking more deeply about the problem. Limiting the number of retries is not what I want to do. At least not globally for all error conditions. For instance if an entire rack or colo of upstream servers are down we don't want to be limited to 2 or 3 retries (especially for connect timeouts) however if there is some other error, or slow response then depending on the type of error we may want to retry at most 1 or 2 times.

Your suggestion to use the error_page is wise.

I continue to be impressed by nginx's depth and power. The fact that such an "easy" feature like
upstream_count_limit doesn't exist is a good thing. If you think you need it, you're probably doing it wrong. :)

Bryn