Nginx session-stickiness

Corey Donohoe atmos at atmos.org
Sun Apr 6 08:23:23 MSD 2008


On Sat, Apr 5, 2008 at 8:41 PM, Rob Mueller <robm at fastmail.fm> wrote:
>
>
>  Have a look at proxy_next_upstream.
>
>  http://wiki.codemongers.com/NginxHttpProxyModule#proxy_next_upstream
>
>  You can turn it on for "error", and if nginx fails to connect to the hashed
> backend, it'll try the next hashed server just as if you'd marked it as
> down.
>

Won't this have the downside of possibly sending multiple failing
requests to the upstreams?  We used this for a while but ran into
problems with duplicate requests.  For example we had people sending
WAY too many mails out in an request, the appserver would timeout
halfway through, it'd send a portion of the emails, and then send the
request to another upstream.  The subsequent requests would do the
same thing and people would get the same email for every upstream
defined.

I think the short answer to the original question is no, but I'd love
to be proved wrong.  ;)  This is why people are offering alternatives
instead of pointing to a clear solution.  FWIW most of our clients use
cookie, database, or memcached based sessions.  Personally I kind of
like the approach of having your application manage session data.


-- 
Corey Donohoe
http://www.atmos.org/
http://www.engineyard.com/





More information about the nginx mailing list