Hi Michael, On Fri, Apr 09, 2010 at 06:04:01PM +0200, Michael Rennt wrote: > Hi, > > according to http://haproxy.1wt.eu/knownbugs-1.3.html > the bug "(M) appsession lookup in URL does not work" is true up to 1.3.14.2. > > I'm currently testing the "appsession" feature with 1.3.22, 1.3.24 and 1.4.4. > > Only 1.4.4 seems to work the way the documentation suggests, using the > following test config: > > global > log /dev/log daemon debug > pidfile /var/run/haproxy.pid > maxconn 8192 > user haproxy > group haproxy > > defaults > log global > retries 3 > option redispatch > maxconn 8192 > > frontend my-frontend x.x.x.x:80 > mode http > log /dev/log daemon info > option httplog > option dontlognull > option httpclose > > default_backend my-backend > > backend my-backend > mode http > option httpclose > #balance roundrobin > #balance url_param JSESSIONID check_post > #cookie JSESSIONID prefix > appsession JSESSIONID len 10 timeout 3h request-learn mode > query-string > server s01 x.x.x.10:80 cookie AAAAAA check inter 5000 weight 22 > server s02 x.x.x.20:80 cookie BBBBBB check inter 5000 weight 22 > > ("mode query-string" only used with 1.4.4, "cookie xxxx" are remains from the > "cookie" parameter) > > My test script is setting a cookie. I call it with > http://test/cookie.php?JSESSIONID=xxxxx > > Dumping the hash table with 1.4.4 shows a "get_srv_from_appsession" for the > appsession in the get > string and a "manage_server_side_cookies" for the cookie from the server (at > least that's what I guess). > > With 1.3.22 and .24 I just get the "manage_server_side_cookies". When I > constantly deny the cookie, > the requests are round robbed, while with 1.4.4 they are sticky from the > first request on, because > the url appsession lookup in the url is working.
Could you please also include a dump of the exchange between the client and haproxy (or even an output of "haproxy -d") ? It is possible that something appears mangled and that we're not thinking about it. > Will this be fixed in 1.3.x or do you suggest to upgrade to 1.4? No, there is no reason to upgrade for something that ought to work. 1.3 is still maintained, so if it is supposed to work and it doesn't, it's a bug and it needs to be fixed. If the fix is too dangerous, we may reconsider this but right now this has not been qualified yet. However, you can use 1.4 as a workaround (or maybe you plan to upgrade for other reasons). > I know about the drawbacks of appsession, i.e. in memory hash lost on reload > or failover. Will there > be some kind of hash table dump and failover to another system? It's currently being developped. It's not specific to appsessions but rather to the new stickiness framework. At one point, appsession will be adapted to make use of it and it will suddenly support this failover. This will not be before 1.5 though. > Why am I even thinking about using appsession? I'm testing appsession because > this seems to be the > best way to overcome stickiness problems which might occur with "cookie" + > "balance url_param" (see > commented out part in the config) on the very first request of a new user. > Maybe there's an option > to this? I don't understand what type of option you're looking for. > The problem I'm seeing: With "cookie" + "balance url_param" the very first > request will be round > robbed, if both cookie and url_param are not present. So if a user has > cookies disabled, after the > first request, the user will click on a link, which includes his session ID > as a parameter. I'm very surprised that you're still seeing users with cookies completely disabled. Persistent cookies are commonly disabled, but session cookies are very rarely in my experience. Even a large site I know with around 2M visitors a day never ever encounters this case in a mixed population. Even mobile devices all support session cookies now. > So with > "balance url_param" the value of the session ID will be hashed and the user > might end up on a > different server, hence information created locally on the system of the > first request will be > unavailable. Further requests will be directed to the same system. I know, in > a cluster user related > data should be kept redundant, but in this case this is not an option. Well, 5-10 years ago, when there were still some browsers not supporting cookies, it was common to use a source address hash as the LB parameter, because if the user does not support cookies AND has a consistently changing IP, you can't do much for him. Here you could use "balance source" and ensure that the ones without cookies will stick to the same server as long as they don't switch their IP. In 1.4, you could even stick on the source IP and hash the URL param (stick has precedence). Multiple sticks are supported though right now we can only stick on IP addresses. Regards, Willy
