[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haproxy
Subject:    Re: session stickyness with or without serverid
From:       Willy Tarreau <w () 1wt ! eu>
Date:       2011-07-29 7:11:38
Message-ID: 20110729071138.GA15486 () 1wt ! eu
[Download RAW message or body]

Hi Julien,

On Thu, Jul 28, 2011 at 07:16:32PM -0400, Julien Vehent wrote:
> Hey guys,
> 
> We've been happy users of haproxy in front of our tomcat farm for some 
> time now, except for one thing: when we want to put a backend in 
> maintenance mode, via hatop, we have to deal with users coming back a 
> few hours later with a SERVERID cookie and being routed to that backend.

If it's in maintenance mode, it should not receive any traffic. I suspect
you just changed its weight to zero, which means it's not elected for LB
but will still serve persistent requests. Please double-check, because if
you're certain that you're getting that, then you've spotted a bug.

> I initially configured haproxy to balance based on a SERVERID cookie, 
> essentially because I didn't know if the JSESSIONID would provide the 
> appropriate persistence, but now I'm thinking that it might be a good 
> idea to remove the SERVERID cookie and do all the work on the 
> JSESSIONID. The goal would be to reduce the time between putting a 
> server in maintenance and not seeing any traffic on it at all (ie. all 
> sessions are expired).
> 
> So my question is: what are the pros and cons of using a SERVERID 
> cookie vs a JSESSIONID ?

Cookie insertion is more reliable and more determinist since there are
no tables to learn and maintain. Also, with recent versions, we now have
features such as "force-persist" and "ignore-persist" which make it a lot
easier to perform maintenance on live service without the user noticing
and with the ability for the admin to check what he's going to put online
before doing so. All these are good reasons to use a SERVERID cookie
instead of learning a JSESSIONID cookie.

Cheers,
Willy


[prev in list] [next in list] [prev in thread] [next in thread]