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:al-hapr...@none.at] Sent: Tuesday, October 27, 2009 2:54 PM
To: haproxy@formilux.org
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


Reply via email to