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
and run it with -db to see what's in the hash.
The request, as it appears in HTTP access_log:
22.214.171.124 - - [28/Oct/2009:00:22:04 +0000] "POST
200 1002 "-" ""
And from haproxy.log:
Oct 28 00:18:20 127.0.0.1 haproxy: 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
This lines are not from the same client or requst right?!
# when cookie persistence is required
#cookie JSESSIONID prefix
appsession jsessionid len 32 timeout 10800000
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.
From: Aleksandar Lazic [mailto:al-hapr...@none.at]
Sent: Tuesday, October 27, 2009 2:54 PM
Subject: Re: Sticky session, dumb client
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
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.
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