Thanks for the reply, Aleks.
appsession lookup in URL does not seem to work for me.
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"
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
-----Original Message-----
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
