Thanks again, Aleks and Willy. This is finally working - not an elegant solution, but as a workaround a SERVERID cookie can be appended onto the request header using Apache mod_header that mimics the one inserted by HAproxy on outgoing responses. So, basically HAproxy sees a "normal" client request, and "cookie SERVERID insert indirect nocache" can work as documented. This is possible because the jsessionid value passed in the URL has the originating server appended to the session information already (apparently that is what mod_jk uses and our software was originally written with mod_jk in mind).
Thanks again for the help! -Mike -----Original Message----- From: Aleksandar Lazic [mailto:[email protected]] Sent: Wednesday, October 28, 2009 1:12 AM To: Robinson, Michael Cc: [email protected] Subject: Re: Sticky session, dumb client On Die 27.10.2009 20:37, Robinson, Michael wrote: >Thanks for the reply, Aleks. > >appsession lookup in URL does not seem to work for me. Please can you rebuild haproxy with DEBUG=-DDEBUG_HASH and run it with -db to see what's in the hash. >The request, as it appears in HTTP access_log: > >64.88.170.40 - - [28/Oct/2009:00:22:04 +0000] "POST >/app;jsessionid=813FD588059604BD3D519A11A0C1FA7B.10.250.54.70 HTTP/1.0" >200 1002 "-" "" > >And from haproxy.log: > >Oct 28 00:18:20 127.0.0.1 haproxy[18330]: 127.0.0.1:46652 >[28/Oct/2009:00:18:20.441] www www/i-c05ddda8 0/0/0/2/2 200 495 - >JSESSIONID=7537BF152E4E826BBD0672DE3AC1A4CE.10 ---- 0/0/0/0/0 0/0 "GET >/ HTTP/1.1" This lines are not from the same client or requst right?! BR Aleks >My haproxy.cfg: > > ... > # when cookie persistence is required > #cookie JSESSIONID prefix > appsession jsessionid len 32 timeout 10800000 > option httpclose > capture cookie JSESSIONID len 46 > # Example server line (with optional cookie and check included) > server srv1 10.253.43.224:8000 cookie srv1 check inter 2000 > rise 2 fall 3 > server srv2 10.253.43.224:8000 cookie srv2 check inter 2000 > rise 2 fall 3 > ... > >Requests are still routed to both servers. It was suggested mod_jk and >jvmRoute settings may be a factor (which seems true with server ID >appended onto jsessionid - I don't have jvmRoute set anywhere); perhaps >I'm overlooking something simple, but there's nothing apparent from the >documentation I've read. > >I tried using the latest dev version of HAproxy too - didn't work. Thoughts? > >Thanks again for the feedback. > >Mike > > > >From: Aleksandar Lazic [mailto:[email protected]] >Sent: Tuesday, October 27, 2009 2:54 PM >To: [email protected] >Subject: Re: Sticky session, dumb client > >Dear Michael, > >On Mon 26.10.2009 21:18, Robinson, Michael wrote: >>I've got HAproxy 1.3.22 configured on two EC2 servers in front of two >>Apache/Tomcat frontends serving a JSP-based mobile phone application. >>The application requires session stickiness - I've tried every >>documented alternative HAproxy offers for session persistence, >>unfortunately without luck. The mobile device (well, our application) >>does not support cookies and will not echo a modified jsessionid cookie >>on subsequent requests. Two options seem ideal, but there are >>roadblocks: >> >>1. appsession jsessionid len 52 timeout 1h >> >>However, since cookies aren't an option, we hoped to leverage >>appsession URL lookup... which has the honor of being on the matrix of >>all known bugs<http://haproxy.1wt.eu/knownbugs-1.3.html> posted on >>10/18 (thanks for posting this, BTW!) >> >>Any ideas if/when this may make it into a stable release? > >It should work in the current release of haproxy. >Do you have faced some problems, or bugs? > >>2. balance url_param jsessionid check_post >> >>This option could work... but it doesn't (for me, at least). Is the >>config line wrong? Here's an example HTTP request from our log file: >> >>... "POST /app; jsessionid=55A964502A7D0565A1C2ADE432AD3EF0 HTTP/1.1" >> >>Can/should I just modify the source for url_param matching to look for >>';' instead of '?' as a workaround? > >This could not work due to the fact that the jsessionid=... is not part >or query string. > >from http://haproxy.1wt.eu/download/1.3/doc/configuration.txt > >### >url_param The URL parameter specified in argument will be looked up in > the query string of each HTTP GET request. >. >. >### > >I think it is not a good idea to change the delimiter from ';' to '?'. > >Maybe you will be happy with 'uri' as lb method? > >Maybe there should be parameter delimiter or regex for the load >balancing algorithm uri? > >E.g.: delimregex ;\\s+jsessionid=([:xdigit:]+) or similar > >BR > >Aleks >
