Feature I'd like to see

[xgdlm]

Hello

Le 4 juin 2010 à 16:30, Almir Karic a écrit :

> The same "problem" that you are describing can be solved with say
> http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream while
> keeping one upstream block.

In my case if I setup a single upstream like this for instance :

upstream guinicorn {
	server 192.168.0.171 max_fails=1 fail_timeout=10s;
	server 192.168.0.172 max_fails=1 fail_timeout=10s;
	server 192.168.0.173 max_fails=1 fail_timeout=10s;
	server 192.168.0.174 max_fails=1 fail_timeout=10s;
	server 192.168.0.175 max_fails=1 fail_timeout=10s;
	server 127.0.0.1 backup;
}

and then I use it for multiple app

------------------------------------
server {
	location / {
		proxy_pass http://gunicorn:3000;
		proxy_next_upstream error timeout invalid_header http_500 http_502 http_504;
	}
}

server {
	location / {
		proxy_pass http://gunicorn:3001;
		proxy_next_upstream error timeout invalid_header http_500 http_502 http_504;
	}
}

server {
	location / {
		proxy_pass http://gunicorn:3002;
		proxy_next_upstream error timeout invalid_header http_500 http_502 http_504;
	}
}
------------------------------------

if one of this app fails badly in five request all the upstream servers are set inoperative.
The behavior I noticed (few years ago, may be this has changed) is that all the app 
using this upstream will be using the backup server. So if one app fails, the other fails to.

May be this behavior has changed, but now I create an upstream for each app and I never had the problem again.


xav


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100604/a07c7d30/attachment.html>